jva.lang.OutOfMemoryError

[Tobias]

High,
ich hab ein Problem mit Threads, kann aber der Masse wegen wohl eher keine Code posten -> liest ja doch keiner . Und zwar starte ich zwei Threads, von denen einer auf der Standardeingabe wartet, bis etwas eingegeben wurde und diese Eingabe dann an den anderen weitergibt, der sie verarbeitet. Leider kommt noch vor dem ersten Prompt der oben genannte Fehler, den ich mir bei meinen 1024 MB RAM aber nicht wirklich erklären kann (zumal zu diesem Zeitpunkt nur der kleine harmlose Warte-auf-Eingabe-Thread laufen dürfte...).
Hat jemand eine Idee, woran das liegen könnte?

mpG
Tobias

 

[Beni]

Ein rekursiver Aufruf ohne Endbedingung?

Ist ohne Code sehr schwer zu sagen...

mfg Beni

P.S. vielleicht wird nicht alles gelesen, aber manchmal kopiert und ausprobiert. Das hilft vielmehr als die (meist) ominösen Fehlerangaben des Autors :wink: 8) :lol: :bae: (das war ironisch gemeint)

 

[Grizzly]

Ich würde einfach mal die Aktionen des Programms mitloggen lassen. Dafür eignet sich beispielsweise die Jakarta Commons Logging Bibliothek. Zusätzlich kannst Du ja mal den Task-Manager von Win2000/XP mitlaufen lassen und Dir die Speicherentwicklung Deines Programmes anzeigen lassen.

 

[Tobias]

Die Fehlermeldung bleibt mir rätselhaft... Der Taskmanager zeigt eine maximale Speicherauslastung von ca 350 MB an, während das Programm läuft. Allerdings scheine ich die fehlerhafte Anweisung ausfindig gemacht zu haben - parseFile(). Diese Methode versucht ein File einzulesen und es zeilenweise dem Parser zu übergeben. Da der aber erst rudimentär vorhanden ist, übergeb ich derzeit eine leere Datei, was in wohl aus der Bahn wirft...
Zur Kommunikation zwischen den beiden Threads benutze ich ein String-Objekt, das - wenn es leer ist, den parsenden Thread zum Warten bringt, bzw wenn es ungleich null ist, den Eingabe-Warte-Thread. Die synchronized-Anweisung kann aber mit null-Objekten nicht umgehen (was ja auch logisch ist, wenn ich es mir recht überlege). Aber wie soll ich das stattdessen handhaben?
Ich speicher in diesem String-Objekt die Zeile, die eingelesen wurde (entweder aus einer Datei oder von der Kommandozeile). Nach dem Parsen setze ich das Objekt wieder auf null -> um zu signalisieren, das es weitergehen kann. Und da liegt wohl der Haken... Hat jemand einen Gegenvorschlag?

mpG
Tobias

 

[Beni]

wait und notify

für beide benötigst du ein synchronized-Block. Bei jedem Object kann man "wait" aufrufen, dann wartet der aufrufende Thread solange, bis ein anderer Thread beim gleichen Object die Methode "notify" aufgerufen hat. Man kann dabei sogar wartende Threads stapeln...

Aber in diesem Fall kannst du nur ein Object verwenden!

 

[Tobias]

Bei mir schaut das im Moment so aus:

public class CommandProcessor implements Runnable {

    private class InputListener implements Runnable {

        boolean runflag = true;

        // nur die run-Methode
        public void run() {
            while(runflag) {
                synchronized(order) {
                    if(order != null) { // unbearbeiteter Befehl liegt vor
                        wait();
                    }
                    else {
                        // String von der Standardeingabe lesen und in order speichern
                       notify();
                    }
                }
            }
        }
    }

    String order = null;
    Command command;
    boolean runflag = true;

    // auch hier nur die run-Methode
    public void run() {
        try {
            parseFile(); // parst das Autostart-File, das z.B. nicht-Kernel-Programme nachlädt
        }
        catch(Exception ex) {
            ex.printStackTrace();
        }

        Thread input = new Thread(new InputListener()).start(); // jetzt starte ich das Horchen auf der Standardeingabe
        
        while(runflag) {
            synchronized(order) {
                if(order == null) { // keine neuen Befehle
                    wait();
                }
                else {
                    command = parse(order); // order zu einem ausführbaren Befehl transformieren
                    execute(command);
                    order = null;
                    notify();
                }
           }
       }
   }
}

Soweit schon fette Fehler?

mpG
Tobias

P.S.: parsefile() ist im Moment auskommentiert, weil deren Ausgaben ja nichts Sinnvolles für den Parser ergeben. Und das der String order nicht null sein darf, wenn ein synchronized-Block betreten wird, weiß ich mittlerweile auch - hier wäre mein Frage, was ich dagegen tue...

 

[Mick]

[...] den ich mir bei meinen 1024 MB RAM aber nicht wirklich erklären kann (zumal zu diesem Zeitpunkt nur der kleine harmlose Warte-auf-Eingabe-Thread laufen dürfte...).

Die Java Runtime nutzt nicht automatisch den gesamten Hauptspeicher aus. Man kann einstellen, wieviel genutzt werden soll.

Beispiel:

java -Xms{S} -Xmx{M}
{S} sind die Bytes, mit denen Java gestartet wird
{M} maximale Größe, Du kannst "M" dahinter setzen, um in MegaByte anzugeben: -Xms16M

Starte Java mit 20 Mb und erlaube höchstens 128 MB Speicher:
java -Xms20M -Xmx128M

Nur mal so zur Info.

Grüße,
Mick

 

[lhein]

1024 MB Ram hast Du wohl, aber Java nutzt standardmäßig nur einen kleinen Teil (glaub 64 MB, bin mir aber nicht sicher). Die Fehlermeldung "Out of Memory" bezieht sich also auf eben diesen kleinen Teil, den sich die JRE reserviert.

Edit: Ha, war zu langsam

 

[Tobias]

Also, da ich schon Speicherverbräuche von weit über 800 MB provoziert habe und das problemlos geklappt hat, kann darin nicht die Erklärung liegen. Spielt abr auch keine Rolle, da ich mittlerweile ein paar substanzielle Fehler in der Klasse aufgedeckt habe und sie daher neu designt habe. Bisher läuft die Implementierung gut, auch wenn ich den letzten Stand aus Zeitmangel noch nicht ganz erreicht habe.

mpG
Tobias