Java Performance Tools – Teil 1 (Grundlagen)

Weitere Magazine

Empfehlungen

Info

Sonderdruck hinzugefügt oder ein bestehender Code verändert. Der Zeitpunkt der Manipulation ist allerdings je nach verwendeter Technologie unterschiedlich. Bei der statischen Bytecode-Instrumentierung wird der Bytecode vor dem Laden der Klassen mit einem Preinstrumentor instrumentiert. Der Bytecode läuft daher auf jeder JVM und es werden keine zusätzlichen Anpassungen oder Libraries zur Laufzeit benötigt. Nachteilig ist, dass ein manueller Schritt für die Instrumentierung notwendig ist und Systemklassen des Runtime Environment nicht instrumentiert werden können. Bei der Load-Time-Bytecode-Instrumentierung wird ein eigener Class- Loader verwendet, der beim Laden einer Klasse den entsprechenden Bytecode einfügt. Alternativ kann auch ein JVMPI-oder JVMTI-Agent verwendet werden, um beim entsprechenden Classloading Event den Inhalt der Klasse zu verändern. Man spart also im Gegensatz zum statischen Ansatz einen manuellen Schritt und kann auch Systemklassen instrumentieren. Dynamische Bytecode-Instrumentierung erlaubt es, den Bytecode einer Klasse auch nachdem sie bereits geladen ist, zu verändern. Diese Möglichkeit existiert erst seit Java 5 und wird daher erst von sehr wenigen Tools unterstützt. Das dynamische Instrumentieren von Klassen wird durch die RedefineClasses-Funktion in JVMTI möglich. Neben JVMTI bietet Java 5 aber auch eine reine Java-Implementierung von Agenten für die dynamische Instrumentierung von Bytecode, die sich im Paket java.lang.instrument befindet. Eigene Agenten zu schreiben, ist relativ einfach, aber nicht nur für Performance-Messungen sinnvoll, deshalb soll nachfolgend beispielhaft die Implementierung eines Agenten in Java beschrieben werden. Das Package java.lang.instrument bietet Agenten die Möglichkeit, den Bytecode von Klassen dynamisch zu verändern. Die Manipulation des Bytecodes kann auf zwei Wegen geschehen. Zum einen zur Ladezeit durch eine Implementierung des Interfaces ClassFile- Transformer. Zum anderen zur Laufzeit, das heißt, auch nachdem Klassen bereits durch einen ClassLoader geladen wurden. Letzteres geschieht durch die Methode redefineClasses(), welche im Interface Instrumentation definiert ist. Zur Veranschaulichung soll ein einfacher Agent entwickelt werden, der beim Laden jeder Klasse eine Meldung mit dem Namen der Klasse auf der Konsole ausgeben soll. Die Dokumentation des java.lang.instrument-Pakets gibt eine Übersicht über Anforderungen an einen Agenten und wie dieser eingebunden wird. Um einen eigenen Agenten zu entwickeln, wird eine Bootstrap-Klasse benötigt. Diese muss über eine Methode mit einer Signatur verfügen, die vergleichbar mit der main-Methode für Java-Applikationen ist: public static void premain(String agentArgs, ... } Instrumentation instrumentation){ Der Methode werden die Parameter für den Agenten übergeben sowie eine Instanz vom Typ java.lang.Instrumentation, die Funktionen zur Instrumentierung von Java-Klassen bietet. Die Veränderung des Bytecodes erfolgt entweder über eine eigeneClassFileTransformer-Implementierung für die Manipulation beim Laden oder Redefinition der Klasse oder direkt über eine neue Klassendefinition vom Typ ClassDefinition, wenn eine Klasse geändert werden soll, die bereits geladen ist. Wird der Bytecode einer bereits geladenen Klasse mit der redefineClasses()- Methode überschrieben, hat dies nur Auswirkungen auf zukünftig aufgerufene Instanzen der Klasse. Instanzen der Klasse die sich in einem aktiven Stack Frame befinden, bleiben von der Änderung unberührt. In dem Beispiel wird ein eigener ClassFileTransformer verwendet, um die Namen der geladenen Klassen auf die Konsole zu schreiben und sie dann unverändert weiterzureichen. Die Implementierung des Interface benötigt nur eine Methode: package de.codecentric.transformer; import java.lang.instrument.ClassFileTransformer; import java.lang.instrument.IllegalClassFormatException; import java.security.ProtectionDomain; public class LogClassFileTransformer implements ClassFileTransformer { public byte[] transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { System.out.println( “Transformiere die Klasse ‘“ + className + “’“); return null; } } Nachdem der LogClassFileTransformer mit addTransformer() bei der Instrumentation-Instanz registriert wurde, wird bei jeder Definition oder Redefiniton einer Klasse die Methode transform(…) aufgerufen. Eine Klassendefiniton erfolgt über ClassLoader.definineClass() während Klassenredefinitionen über Instrumentation.redefineClasses() erfolgen. Innerhalb der Methode ist es möglich, den Bytecode der Klasse zu verändern. Der Bytecode muss dem Classfile-Format der JVM-Spezifikation [2] entsprechen. An dieser Stelle bieten sich zur vereinfachten Manipulation verschiedene Open-Source-Tools wie Apache BCEL, ObjectWeb ASM [3] oder JBoss Javassist [4] an. In unserem Beispiel wird die Klasse nicht verändert, weshalb in der transform()-Methode null zurückgeliefert wird. Der Code für den Agenten sieht wie folgt aus: package de.codecentric.instrument; import java.lang.instrument.Instrumentation; import de.codecentric.transformer. LogClassFileTransfor- Sonderdruck www.javamagazin.de mer; public class JMVTIAgent { public static void premain(String agentArguments, Instrumentation instrumentation) { } } instrumentation.addTransformer( new LogClassFileTransformer()); Der Agent kann jetzt mit jeder beliebigen Java-Anwendung zusammen gestartet
werden, um die Klassennamen auf der Konsole auszugeben. Hierzu muss der Agenten-Code aber noch in ein JAR gepackt werden, das über eine spezielle MA- NIFEST.MF-Datei verfügt: Manifest-Version: 1.0 Premain-Class: de.codecentric.instrument.JMVTIAgent Mithilfe des Java-Kommandozeilen-Parameters -javaagent:jarpath[=options] kann der Agent und die agentenspezifischen Parameter definiert werden. Das Beispiel zeigt, dass man mit einem java. lang.instrument-Agenten ohne C oder C++ Code schreiben kann, der spezifische Funktionen in bestehende Java-Anwendungen einfügen kann. Viele AOP Frameworks basieren auf dieser Technologie, um Aspekte in die Anwendungen zur Laufzeit „einzuweben“. Für Profiler- und Diagnose-Tools ist vor allem die Plattformunabhängigkeit des Agenten und die Möglichkeit, Klassen dynamisch zu verändern, interessant. Die Technologie www.javamagazin.de Abb.1: Java Management Layer ermöglicht zum Beispiel das Entfernen und Hinzufügen von Messpunkten zur Laufzeit. Java Management Extension (JMX) Neben den Laufzeitinformationen, die über die Bytecode-Instrumentierung erzeugt werden, sind für das Monitoring von Anwendungen vor allem auch Informationen über die Infrastrukturkomponenten notwendig. Hierzu zählen auf der untersten Ebene Informationen der JVM, wie Heap-Statistiken oder Thread Informationen. Bei Java EE ist aber auch die Auslastung der Application-Server-Ressourcen notwendig, um Performance-Engpässe Sonderdruck identifizieren zu können. Beispielsweise können zu klein gewählte Thread- und Datenbank-Connectionpools dazu führen, dass Benutzeranfragen in einer Warteschlange landen und sich die Verarbeitung verzögert. Aber auch Statistiken von Caches aus eigenen Komponenten oder Frameworks wie Hibernate [5] sind von Bedeutung, wenn ein Bottleneck in einer Anwendung gefunden oder Ressourcen-Engpässe in Produktion frühzeitig identifiziert werden sollen. Mit der Java Management Extension (JMX) steht eine ausgereifte Spezifikation zur Verfügung, die eine Überwachung von Applikationen und Services einfach möglich macht. TM Das neue Portal für Java, Enterprise Architekturen , SOA. Anzeige NEU! Sonderdruck www.jaxenter.de
Seite 1 und 2: 12.07 Mit CD • Acegi Security 1.0
Seite 3: ten technischen Probleme komplexer
Seite 7 und 8: •Den Status für die Überwachung

Java Performance Tools – Teil 1 (Grundlagen)

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?