Letzte Woche durfte ich zur Weiterentwicklung meiner Java Fertigkeiten den Java Specialists Master course von Heinz Kabutz besuchen. Java Champion Heinz, ist ein hervorragender Trainer, der es geschafft hat Anekdoten, harte Fakten und tiefe Javakenntnisse zusammen mit herausfordernden Übungen zu einem großartigem Kurs zusammenzustellen. Der Umfang betraf das gesamte Spektrum von Java, jedoch lag der Fokus auf den kleinen Gemeinheiten die man entweder nicht kennt oder nicht nutzt. Auszüge des Kursmaterials veröffentlichte er bereits in seinem Newsletter , welcher eine große Leserschaft weltweit besitzt.
Im folgenden möchte ich meine Eindrücke der 4 Tage schildern…
Tag 1
Direkt mit einem komplexen Thema ging es Dienstag früh los: Thread, wie funktionieren sie und was gibt es zu beachten. Wir haben eine ThreadGroup erstellt und zu einem eigenem Thread pool ausgebaut. ThreadGroup ist nun leider nicht die allerschönste Klasse. Heinz verglich sie mit einer Art Kinderzeichnung aus den frühen Java Jahren. besonders einfach zu benutzen fand ich die java.util.concurrent Locks , welchen ich bisher weniger Beachtung schenkte. Endlich sind die Zeiten von synchronized() vorbei. Noch vor dem Mittagessen erläuterte Heinz uns seine Gesetze über Nebenläufigkeit, welche er bereits in verkürzter Form auf unserem meet the experts – performance event präsentierte. Dabei stolperten wir über folgenden code:
1private boolean running = true;
2public void dojob() {
3 while(running) {
4 // do something useful
5 }
6}
7public void shutdown() {
8 running = false;
9}
Führt man diesen auf einer Server VM aus (java -server), so kann es passieren daß der Code sich nicht mehr beendet, da die HotSpot engine den Code optimiert, da running scheinbar immer true ist. Um dies zu vermeiden muss es volatile gemacht werden. Da ich nach Debugging fragte versuchten wir in der Schleife anzuhalten und sieh da, der Debugger zeigte und: running = false. Dies hielt aber den laufenden Code nicht davon ab weiterzulaufen, da der Debugger zwar den korrekten Wert sieht, der laufende Code aber nicht. Doch es wird noch interessanter:
1public void doJob() {
2 boolean myRunning = running;
3 while(running){
4 // do something useful
5 myRunning = running;
6 }
7}
Nun zeigt uns der Debugger dies:
1running = false; myrunning = true;
trotzdem läuft der code weiter. Jedoch nur so lange bis wir mittels F7 die Zeile ausführen ließen. Diese Art von Problemen kann ein Alptraum werden, deshalb ist es wichtig zu wissen was man korrekterweise tun muss.
Auch wissenswert war es zu erfahren, daß
1if (Thread.interrupted()) { 2 throw new InterruptedException() 3}
der erste Code in jeder Methode sein sollte welche eine InterruptedException deklariert.
Wir haben außerdem den CompletionService kennengelernt, welches nach einem interessanten Interface für die Bearbeitung von asynchronen Aufgaben aussieht. Wer braucht da noch closures? 🙂
Tag 2
Wir begannen Tag 2 mit Java new (yet another new?) IO, welches recht viele Features mitbringt, aber irgendwie doch selten verwendet wird. Möglicherweise liegt das an der teilweise sperrigen Benutzung der Interfaces. Man sollte doch vielleicht einfache Beispiele probieren bevor man sich an einem asynchronen nichtblockierendem Server versucht (was man aber durchaus nach Besuch des Kurses kann 🙂 ).
1FileChannel fc = new RandomAccessFile("test.txt", "r").getChannel(); 2MappedByteBuffer buffer = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size());
Die zweite Tageshälfte verbrachten wir in den Untiefen der Java Speicherverwaltung. Natürlich ist die Praxistauglichkeit des Themas reduziert, doch das Verständnis ist essentiell um Probleme zu verstehen und zu lösen. Wir sahen uns caching und pooling an und betrachteten warum dies Objekte leaken oder herumlungern lassen kann. Das Thema erinnerte mich an einen alten post über tag pooling in Servlet Containern. Ich habe nie wirklich verstanden warum Tags gepoolt werden müssen, und wieso Tags keine erkennbaren Lifecyclemethoden besitzen anhand derer man das Pooling erahnen könnte. Als Tools setzten wir jVisualVm und HPjMeter ein, um den Garbage Collector bei seiner Arbeit zu beobachten.
Tag 3
Ich lernte einige interessante Verhaltensweisen von bislang von mir nicht benutzten Collection Klassen, wie zum Beispiel PriorityQueue kennen, sowie einige Besonderheiten von Classloading. Heinz schaffte es java.lang.reflect.Proxies hervorragend zu erklären, so daß die Anwendung in der Übung leicht viel. Genaugenomen ist die beste Erklärung Teil der JavaDoc, doch man muss erst verstehen wie man diese zu lesen hat:
1Foo f = (Foo) Proxy.newProxyInstance(
2 Foo.class.getClassLoader(), new Class[] { Foo.class },
3 new InvocationHandler() {
4 public Object invoke(Object foo, Method method, Object[] arguments) throws Throwable {
5 return method.invoke(foo, arguments);
6 }
7 });
Nachmittags diskutierten wir über Exceptions, und ich hatte Gelegenheit mir eine begründete Meinung über die Verwendung von checked vs. unchecked Exceptions zu bilden. Ich werde in Zukunft unchecked Exceptions für Entwickler- bzw. Programmierfehler verwenden. Diese zu fangen ist nicht nötig, die Anwendung mag sogar Abstürzen, aber der Fehler muss behoben werden. Jedoch alle umgebungs-, oder installationsrelevanten Besonderheiten werde ich mit checked Exceptions behandeln. Idealerweise bieten diese brauchbare Informationen damit der fangende Code eine brauchbare Fehlerbehandlung durchführen kann. Eine weitere wichtige Erkenntnis: Einfach Exceptions weiter werfen! Ich weiß gar nicht genau warum ich das bisher kaum tat. Wahrscheinlich wollte ich meine Methodensignaturen einfach sauber halten. Dabei ist weiter werfen oft die beste Alternative. Insbesondere die InterruptedException, welche sowieso nur sinnvoll im Threadcode behandelt werden kann (mit Aufruf von interrupted() und dem Verlassen der Schleife).
Tag 4
Der letzte Kurstag begann mit einer echt harten Nuss. Es galt die Performance einer Methode drastisch zu verbessern. Doch Heinz ließ uns nicht an die Optimierung, bevor wir nicht alle Zahlen in verschiedenen Szenarien hatten. Zuvor galt es sogar noch zu beweisen, daß unser Testcode keinerlei Auswirkungen auf die Performance des zu testenden Codes hatte. Ich fand dies besonders lehrreich, da ich durchaus manchmal vergessen habe das Problem zu beweisen, bevor ich mit der Lösung begann. Als Randnotiz betrachteten wir die verschiedenen Modi der JVM und fanden heraus wie langsam java -Xint ist. Nachdem ich endlich den Code auf 10% seiner Laufzeit kürzen durfte gingen wir über zu den letzten Themen des Kurses. So behandelten wir kurz Datum und Zeit, wobei ich doch lieber jodatime oder icu4j nutze und versuche java.util.Date zu vermeiden. Zuletzt sahen wir uns noch Logging und einige Kniffe zur Optimierung von Loggingausgaben an. Die wichtigste Botschaft bei Logging ist Code Wächter zu verwenden. Zwar war mir die Technik bekannt, der Name dafür jedoch neu:
1if (log.isDebugEnabled()){ 2 log.debug(complexObject.toString() + expensive.toString()); 3}
Wrap-Up
Ich kann den Kurs bedenkenlos weiterempfehlen. 4 randvoll mit Informationen und Übungen gefüllte Tage sind derartig gestaltet, daß sie auch für erfahrene Entwickler herausfordernd sind. Als Teilnehmer sollte man unbedingt einige Zeit mit Java gearbeitet haben um die Nuancen und Besonderheiten zu erkennen. Anfänger könnten zwar folgen, verpassen aber interessante Aspekte, da das Tempo recht hoch ist. Ferner empfehle ich den Kurs in Deutsch zu besuchen, da Heinz unterhaltsamen Akzent hat 🙂
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.