Here is a ClassLoader. He is a little bit shy.

Jevgeni Kabanov, Do You Really Get ClassLoaders? (JavaOne Rock Star 2012)

Jevgeni Kabanov jest założycielem ZeroTurnaround - firmy odpowiedzialnej za takie produkty jak JRebel i LiveRebel. Prezentacja jest lekka i przystępna. Najistotniejsze informacje:

1. Każdy ClassLoader ma rodzica (ClassLoader WAR ClassLoader < EAR ClassLoader < Container ClassLoader). ClassLoader wpierw zapyta rodzica, czy ten nie może załadować klasy, a dopiero później spróbuje sam to zrobić. Za wyjątkiem ClassLoaderów WAR-a - te wpierw spróbują załadować klasę, a dopiero później przekażą zadanie rodzicowi.

2. Diagnozując problem z ClassLoaderami (ClassNotFoundException, NoClassDefFoundError, NoSuchMethodError, AbstractMethodError, ClassCastException, IllegalAccessError, LinkageError, ...) warto wyświetlić wyniki poniższych wywołań: Można też użyć argumentu jvm -verbose:class.

3. Obiekt posiada referencję do klasy, klasa posiada referencję do ClassLoadera, ClassLoader posiada referencję do załadowanych przez siebie klas, klasy posiadają referencje do swoich statycznych pól.

Prezentacja przedstawia, jak może to doprowadzić do wycieku pamięci przy redeployu. Tworzymy nowy ClassLoader, ładujemy klasy od nowa, kopiujemy jakiś stan, przy czym jedna z kopii zachowuje referencję do swojego oryginału - i w pamięci pozostają stare klasy, przykładowo z pokaźnymi statycznymi mapami robiącymi za cache.

Co za tym idzie - na produkcji robimy restarty a nie redeploye.

OutOfMemory Error

Opcje wymuszające utworzenie heap dumpa (.hprof) po wystąpieniu OutOfMemory:
- XX:+HeapDumpOnOutOfMemoryError
- XX:HeapDumpPath=[desired .hprof file location]

Plik .hprof można wygenerować na żądanie, programem jmap:
jmap -dump:file=[file name] [pid]

Plik przeanalizujemy np. Eclipse Memory Analyser-em (dostępnym jako wtyczka do eclipse oraz w wersji standalone).

Do podglądu działającej aplikacji można użyć narzędzia jvisualvm (lub jconsole), wchodzącego w skład JDK. Połączymy się zarówno z lokalnym procesem, jak i wirtualną maszyna działającą na innym serwerze (z pewnymi ograniczeniami).

Aby umożliwić zdalne połączenia do tomcata, dodajemy opcje:
-Dcom.sun.management.jmxremote.port=[np. 8086]
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

GC overhead limit exceeded

Błąd "java.lang.OutOfMemoryError : GC overhead limit exceeded" jest wyrzucany w sytuacji, gdy większość czasu (98%) poświęcana jest na odzyskiwanie pamięci, przy czym udaje się uzyskać mniej niż 2% sterty. Co jest w pełni uzasadnione - gdy zużycie dostępnej pamięci niebezpiecznie zbliża się do 100% i niewiele z tego daje się odzyskać - aplikacja potrafi dogorywać w nieskończoność.

Parametrami (ilością czasu oraz odzyskanej pamięci) można sterować poprzez opcje:
-XX:GCTimeLimit=[time limit]
-XX:GCHeapFreeLimit=[space limit]
Funkcjonalność można wyłączyć, dodając: -XX:-UseGCOverheadLimit.

Źródła:
GC Tuning (Excessive GC Time and OutOfMemoryError)
GC Ergonomics

Tricky is, handling dates in Java. Joda Time, you shall use!

Java Date API jest dalekie od ideału. Przede wszystkim brakuje w nim metod dla podstawowych operacji, a napisanie ich wymaga absurdalnej ilości kodu i ostrożności.

Właśnie utworzyliśmy datę reprezentującą 6.02.3913. Miesiące liczymy od zera. A lata od 1900.
Tym razem dostaniemy 6.02.2013. Lepiej, choć wciąż nieidealnie.

Klasyczny przypadek - chcemy porównać dwie daty, z dokładnością do dni. Czas wyzerujemy w następujący sposób:

Wystarczy powtórzyć dla drugiej daty i możemy porównywać.

Inny klasyczny przypadek - chcemy obliczyć ilość dni między dwoma datami. Jedno z prostszych rozwiązań wygląda następująco:


Alternatywy?

Apache Commons Lang - DateUtils


Date4J

Malutka biblioteka, obejmuje zaledwie kilka klas. Tutaj znajdziemy krótkie porównanie z Joda Time.


Joda Time

Chyba najpopularniejsza, obszerna biblioteka do obsługi dat.