JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 195 contents

https://www.youtube.com/watch?v=GiWXvj-ZtWA
JavaDay Kiev JVM Tuning Workshop 1 (Page last updated January 2017, Added 2017-02-27, Author Tomasz Borek, Publisher JavaDay). Tips:

• Monitoring puts you ahead of game. Hava plan of action for identifying issues. Establish baselines (traffic, etc).
• Recent changes are mostly the cause of any change in performance.
• A thread per request can't scale. You need to have controllers and worker pools. Tuning the pools is essentials.
• The OS and user limits limit your JVM use of resources - Memory, Heap (for Java objects), C-heap (full process space), ulimit for threads and files.
• Linux OOMKiller can be arbitrary, be careful with it.
• The most common reasons for out of memory is: the heap space getting full (too many objects or heap space not big enough); the PermGen or Metaspace getting full; unable to create a native thread (the OS has no more free native memory available).
• If you are running multiple JVMs on the same box, you may want to ensure Xmx and Mxs are not the same, so that JVMs can minimize the memory used and so allow OS memory resources to be available to other JVMs.
• GC flags let you size Eden & Survivor spaces (which affects how often GC occurs); how many times an object can be copied in Survivor spaces before moving to the old generation; and more.
• [part 2 at https://www.youtube.com/watch?v=bWFQVcnVXN8 but low information content]

https://www.youtube.com/watch?v=5WQ3HZOerD4
The Basics Of Reactive System Design For Traditional Java Enterprises (Page last updated December 2016, Added 2017-02-27, Author Sean Walsh, Duncan Devore, Publisher Lightbend). Tips:

• For distributed systems, some response (however errored) is much more important than no response at all.
• The CAP theorem says you can't be all three at the same time of consistent, available, and handling partial failure if you're distributed (you can be if you have a monolithic application). Many distributed applications choose eventually consistency - especially if globally distributed.
• Domain Driven Design Bounded Contexts map nicely to microservices. For data interchanged, each microservice should validate the data and transform it to the representation that is most useful for the microservice.
• Optimal microservice architecture would split a microservices into an updateable microservice and a queryable microservice so that each part can be optimized for their usage.
• Reduce the dependencies between microservices by using an event bus as the communication layer, and publish all events to the bus and subscribe to the bus for those events needed by each microservice.

http://www.javamagazine.mozaicreader.com/JanFeb2017#&pageSet=29&page=0
Creating Your Own Debugging Tools (Page last updated January 2017, Added 2017-02-27, Author Andrei Pangin, Publisher Oracle). Tips:

• jvmstat includes several hundred indicators covering nearly all JVM areas: class loading, garbage collection, multithreading, just-in-time compilation, etc. jvmstat counters are free - Java HotSpot VM exports them anyway, whether you read them or not, in the file system as a memory-mapped file in a temporary directory, by default /tmp/hsperfdata_{user}/{pid}, where {pid} is the JVM process ID.
• The jvmstat API is supplied with the standard JDK bundle, just include {JAVA_HOME}/lib/tools.jar (with Java 9 you'll also need to break module encapsulation, eg java --add-exports jdk.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED MyTool). Eg getting process IDs of all JVMs running is just MonitoredHost.getMonitoredHost((String) null).activeVms().
• jvmstat includes interesting metrics that are not found many other places, for instance total time spent in class initializers (sun.cls.classInitTime), number of contended synchronizations (sun.rt._sync_ContendedLockAttempts).
• The Java API for Dynamic Attach is supplied with the standard JDK bundle, just include {JAVA_HOME}/lib/tools.jar. Attaching is simple with VirtualMachine.attach(pid). Typically you would then load an agent (VirtualMachine.loadAgent()) - check the java.lang.instrment.Instrumentation class for details.
• The -XX:+DisableAttachMechanism flag prevents agents attaching to a JVM.
• Dynamically attaching and loading an agent can be enough to fix many issues - typically you change methods and update fields, which often sufficient to fix most problems.
• The Serviceability agent is supplied with the standard JDK bundle, just include {JAVA_HOME}/lib/sa-jdi.jar. You would typically extend an existing Tool class, adding custom logic in the overridden run method. VM.getVM() is a common starting point to access JVM internal structures. The Serviceability agent can read live Java processes and core dumps - it bypasses Java level security by reading the JVM data structures. The JVM is suspended while agent processes, and OS level security still applies, ie you need the right system level access to be able to attach to a process of core.

http://www.egimaben.com/java-garbage-collector-and-reference-objects/
Java Garbage Collector and Reference Objects (Page last updated January 2017, Added 2017-02-27, Author Bengi Egima, Publisher egimaben). Tips:

• Any object referenced from the field of an object which is strongly reachable (apart from Reference objects), or from a live variable on the stack, is itself strongly reachable. It only becomes eligible for garbage collection when the variable/field is nulled or the referring object is itself no longer strongly reachable. Strongly reachable objects are not eligible for garbage collection.
• An object which is not strongly reachable but is reachable via a SoftReference is softly reachable. Softly reachable objects are collected when the JVM is under memory pressure, the actual algorithm for collection is JVM dependent (it's a combination of how long the object has been live, and how little space there is left). Soft references are intended for use in memory-sensitive caches.
• An object which is not strongly reachable nor softly reachable but is reachable via a WeakReference is weakly reachable. Weakly reachable objects can be collected by the JVM whenever it wants (ie as soon as they are no longer stringly reachable, it can be cleared - [Cliff Click once mentioned that programmers really don't realise this, and when he made the Azul collector aggressively clear weakly reachable objects - like the millisecond they become weakly reachable - it exposed bugs in programs such that they had to make the collector less aggressive]). Weak references are intended for use in canonicalized mapping.
• PhantomReferences should be used instead of Object finalizers (ie overriding the Object.finalize() method). unlike soft and weak reference, PhantomReference is useless without a ReferenceQueue. When the object wrapped by the PhantomReference is no longer strongly nor softly nor weakly reachable, the PhantomReference object will be added to the ReferenceQueue, which you can then process for whatever cleanup job is needed. Typically you would subclass the PhantomReference class and put specialized behaviour in the subclass to enact the cleanup (since the referent object, ie the object wrapped by the PhantomReference, is no longer accessible, you need to store somewhere the data for cleaning up after it, whihc can be by a map, or by adding fields to the PhantomReference subclass).

Jack Shirazi

Back to newsletter 195 contents