Schlagwort-Archive: IDE

Java: Falscher ResultSet.getter verursacht Memory Leak

Java, , , , , ,

Ich bin ein Gänseblümchen im Sonnenschein
und durch meine Blüte fließt die Sonne in mich rein
Ich bin ein Gänseblümchen und mir wird ganz warm
ich könnt die ganze Welt und dann mich selbst umarmen.
Ich bin ein Gänseblümchen ohne Aggression
Wut, Ärger – was bringt das schon?

JavaDurchatmen, Freakcommander! Momentan gehst du durch die harte Schule einer dir immer noch relativ unbekannten Sprache. Da fällt man mal hin und muss wieder aufstehen, ansonsten wird das nichts.

Die Vorgeschichte

Aber man muss zugegeben, dass der heutige Fehler nicht ganz so leicht zu finden war:

  • Ich habe die Klasse Host umgeschrieben. Vorher hat sie einfach per Methode .toDB() ihre Attribute in die Datenbank geschrieben. Nach dem Umschreiben soll sich die Klasse nur dann in die Datenbank schreiben, wenn sie entweder noch nicht in der DB ist oder ein Attribut sich verändert hat und die DB somit aktualisiert werden muss.
    Grund für das Umschreiben: Innerhalb eines Programmaufrufs werden hintereinander Millionen Instanzen erzeugt und geguckt, ob sie sich verändert haben. Wenn das der Fall ist, muss der Eintrag auch in der DB aktualisiert werden. Da aber UPDATE oder INSERT-Befehle teurer sind und nur ein sehr kleiner Teil der Millionen Einträge sich auch wirklich verändern, macht eine Überprüfung, ob ein UPDATE oder INSERT erfolgen muss, definitiv Sinn.
  • Wie bin ich vorgegangen?
    1. Eine Methode .getFromDB, die die „alten“ Daten aus der DB liest
    2. Eine Methode .equals, die eine Instanz des Objekts mit einer anderen Instanz vergleicht und TRUE zurück gibt, wenn die Attribute gleich sind
    3. Die alte Methode .toDB() dementsprechend angepasst. Einziges Manko war, dass ich in dieser Methode eine Instanz des eigenen Objektes anlegen musste – diese angelegte Instanz des eigenen Objekts bekommt mittels .getFromDB() die alten Daten verabreicht und wird dann mit .equals verglichen.
  • Das Anpassen des Quellcodes war schnell erledigt. Das große Problem war nun allerdings, dass die Anwendung jetzt ein Speicherleck hatte. Der benutzte Speicher wuchs und wuchs und endete schließlich in einer Exception.
  • Anstatt mich direkt mit dem Code zu beschäftigen und durch auskommentieren und System.out.println-Meldungen dem Problem auf die Schliche zu kommen, beschäftigte ich mich mit der Literaturrecherche zu Memory Leaks, Speicherlecks, Garbage Collector und Eclipse Memory Analyzern oder VisualVM, einem Tool, das eine Realtime Heap-Usage Analyse verspricht.
  • Beim Eclipse Memory Analyzer funktionierte das Generieren der .hprof-Datei nicht, die man braucht, um den Analyzer einzusetzen.
  • Und die VisualVM ist sicherlich ein tolles Tool, aber mein uralt Notebook, welches zu wenig RAM und CPU-Leistung hat, arbeitet so langsam mit der VisualVM, dass beim Start schon der Java-Prozess mit meiner Anwendung, die den Memory Leak hat, verschwunden war. So konnte ich leider keinen Memory-Monitorer einschalten oder den Heap dumpen.. No chance.
  • Und nach stundenlanger Recherche und antesten etlicher Tools, um einem Speicherleck in Java zu begegnen, bekam ich schon wieder dieses Gefühl: Wie kann es sein, dass eine Programmiersprache, die millionenfach eingesetzt wird, kein einfach zu installierendes Tool hat, welches automatisch die Daten sammelt, um einem dann vorzuschlagen, welche Klassen oder Methoden man sich nochmal genauer anschauen sollte, um das Speicherleck zu schließen. Wenn in Foren ein Programmierer Probleme mit einem Tool hat, wird ihm einfach ein anderes Tool empfohlen, welches ähnlich ist und bei ihm laufen sollte. Na ja, ich hatte keinen Bock mehr mich durch irgendwelche Seiten und Tools zu klicken.
  • Das Problem war an irgendeiner Stelle in meinem Code, also finde ich einfach die Stelle und behebe das Problem.
  • Nachdem ich sichergestellt hatte, dass sämtliche Statements, PreparedStatements, ResultSets und Connections nach getaner Arbeit auch wieder geschlossen wurden und das Problem nach wie vor auftrat, kümmerte ich mich um die Instanz, die innerhalb der .toDB()-Methode erzeugt wird. Vielleicht werden ganz viele Instanzen erzeugt, die der Garbage Collector aus irgendwelchen Gründen nicht löschen kann. Aber auch daran lag es nicht.
  • Schließlich ging ich dazu über ganze Funktionen und Programmteile auszukommentieren. Folgender Programmcode verursachte das Speicherleck

Der Fehler

In der Methode .getFromDB(), die einfach nur per DB-Query Daten einliest, gab es folgende 3 Zeilen Code, die Grund für das Memory Leak waren:

[code lang=’java‘]this.setM_swap(rs.getInt(16));
this.setD_total(rs.getInt(17));
this.setD_free(rs.getInt(18));[/code]

Aus dem ResultSet der DB-Abfrage werden per Setter-Methoden die Attribute gesetzt. Das Problem? Da die Java-Datentypen und die DB-Felder für m_swap, d_total und d_free mit Integer bzw. int nicht ausreichend lang waren, habe ich sie nachträglich auf long bzw. Bigint (DB) geändert. Dabei habe ich auch die setter wie setM_swap() so geändert, dass sie als Parameter long erwarten.  Normalerweise schreit ja gleich das IDE los, wenn ein Typ nicht passt, aber Java findet (und in diesem Fall völlig zu Recht), dass Methoden, die long als Parameter erwarten, auch mit int gefüttert werden können und hat deswegen nicht gemeckert.

Das Memory Leak kann ich mir nur so erklären, dass mit rs.getInt auf eine Spalte zugegriffen wurde, welche in der Datenbank als BigInteger definiert ist.

Richtigerweise hätte man mit rs.getLong() arbeiten müssen, dann gibt es auch keine Probleme mit dem Speicher. ;)

Liefert mich ein! Sofort!

Java, , ,

Das Leben ist hart, grausam und gemein! Und heute ist es noch ein bißchen fieser als sonst.

Ich wage mich gerade in die Tiefen von Java vor. Zwar hatte ich in der Uni etliche Kurse zur Java-Programmierung, aber man ist erst in einer Programmiersprache richtig drin, wenn man etwas größeres damit erstellen muss. Das Problem ist nur, dass man immer wieder an seine sprachlichen Grenzen stößt, viel nachschlagen muss und sich auch mit der Komplilierung & Ausführung von Java nicht wirklich auskennt. Theoretisch ist alles klar, aber das Praktische ist meist etwas komplizierter als gedacht.

Nachdem ich die letzten Tage etliche Zeilen Java-Code geschrieben hatte, wollte ich mich heute ran setzen und das Ganze von meinem lokalen Eclipse auf den Server bringen. Ich machte mir ein wenig Sorgen, ob ich die DB-Verbindung auf einer Linux-Maschine zum Laufen kriegen würde, zudem nutzte ich ein paar externe Java-Bibliotheken (jar), deren Pfade ja schließlich auch angepasst werden mussten.

  • Mein erster Ansatz einfach die Export-Funktion von Eclipse zu nutzen und das Ding in eine jar-Datei zu exportieren, funktionierte nicht. Die referenzierten Bibliotheken waren nicht bekannt.
  • Der Versuch die Angaben der .classpath-Datei im Editor auf die Serverpfade anzupassen und dann in Eclipse zu kompilieren, schlug auch fehl, da Eclipse die referenzierten Bibliotheken nicht mehr finden konnte.
  • Auch die Idee beim CL-Aufruf den classpath mit zu übergeben, brachte kein Erfolg
  • Ich landete dann auf der Seite von Thorsten Stein, der mit Apache Ant arbeitet, um eine Jar mit zusätzlichen Libraries zu bauen.
  • Mir kam das zu kompliziert vor. Ich wollte doch nur etwas umsetzen, was Millionen Java-Entwickler Tag für Tag machen: Ein Projekt kompilieren, welches zusätzliche Libraries verwendet. Das kann doch nicht so kompliziert sein!!!
  • Aber anscheinend ist es das: Ich landete schließlich bei FatJar einem Plugin für Eclipse, welches sich dafür rühmt, ein Jar erstellen zu können, welches weitere Jars enthält. Genau das, was ich wollte. Aber auch hier geschah nicht das, was ich wollte.
  • Langsam verzweifelte ich. Rufe ich vielleicht einfach nur mein Programm falsch auf? java -jar meineAnwendung.jar – Das muss doch richtig sein!
  • Die Stunden vergingen und ich machte absolut gar keine Fortschritte und offensichtlich gab es im Internet auch kaum jemanden, der ähnliche Probleme hatte. Es gab zwar viele Suchergebnisse, aber da waren die Probleme meist anders gelagert…
  • Ich entschloss mich, das Tutorial von Thorsten Stein abzuarbeiten. Toll: Ant installieren. Toll: Ant braucht JDK. Toll: JDK installieren!
  • Ich erhielt schließlich die jar mit den externen Libs und lud es auf den Server. Ich führte es aus. Wieder nichts.
  • Ich war mit meinem Latein am Ende. Seit 7 Stunden saß ich an diesem Problem und bekam es nicht gelöst.
  • Komisch, dass der Logger, den ich in meiner Anwendung verwende, eine leere Datei erzeugt. Moment! Könnte es sein, dass das Programm doch ausgeführt wird und nichts macht, weil es nichts gibt, was es machen muss?
    Ja, denn das Ergebnis dieser Abfrage ist auf dem Server leer:
    ResultSet rs = stmt.executeQuery("SELECT idprojects FROM projects WHERE download_url IS NOT NULL AND short_name IS NOT NULL AND (status != 1 OR status != 6)");
    while (rs.next()){
    Project pro = new Project(rs.getInt(1));
    pro.update();
    }

Ich hatte also den ganzen Tag damit zugebracht, einen Fehler zu finden, den es gar nicht gibt.

PHP: Foreach Variablen Typ definieren

Computer, , ,

Ja, die Welt ist leider nicht so ganz einfach. Nachdem ich in diesem Beitrag über die Typisierung von Klassenattributen etwas geschrieben habe, dachte ich, dass man Variablen in der foreach-Schleife ebenfalls so typisieren kann. Felix‘ IDE kann das wohl auch mit folgender Methode
[code lang=’php‘]foreach($this->kunden as $kundeData)
{
/**
@var Kunde
*/
$kunde = $kundeData[‚kunde‘];
[…]
}
[/code]

NetBeans kriegt es allerdings so nicht hin, dort muss man diesen Code verwenden:
[code lang=’php‘]foreach($this->kunden as $kundeData)
{
/* @var $kunde Kunde */
$kunde = $kundeData[‚kunde‘];
[…]
}
[/code]
Und zwar genau mit oben angegebenen Format. Sobald eine Abweichung drin ist (ein Slash zu viel), geht’s schon nicht mehr. Sehr entwicklerfreundlich! :)

[via NetBeans Blog]