Questions et reponses d'entretien

The Z Garbage Collector, or ZGC, promises not to exceed pause times of 10 ms while reducing overall application throughput by no more than 15% compared to the G1GC (the reduction in throughput is the cost of low latency).

ZGC supports heap sizes from 8 MB up to 16 TB.

The pause times are independent of both the heap size and the number of surviving objects.

Like G1, ZGC is based on regions, is NUMA compatible and can return unused memory to the operating system.

You can configure ZGC with a "soft" heap upper limit (VM option -XX:SoftMaxHeapSize): ZGC will only exceed this limit if necessary to avoid an OutOfMemoryError.

To activate ZGC, use the following VM option:

-XX:+UseZGC

Just like ZGC, Shenandoah promises minimal pause times, regardless of the heap size.

You can read about exactly how Shenandoah achieves this on the Shenandoah wiki.

You can activate Shenandoah with the following VM option:

-XX:+UseShenandoahGC

Just like G1 and ZGC, Shenandoah returns unused memory to the operating system after a while.

There is currently no support for NUMA and SoftMaxHeapSize; however, at least NUMA support is planned.

Biased locking is an optimization of thread synchronization aimed at reducing synchronization overhead when the same monitor is repeatedly acquired by the same thread (i.e., when the same thread repeatedly calls code synchronized on the same object).

In the example above, this means that the first time the add() method is called, the vector monitor is biased to the thread in which the test method is executed. This bias speeds up the monitor's acquisition in the following 9,999,999 add() method calls.

Biased locking mainly benefits legacy applications that use data structures such as Vector, Hashtable, or StringBuffer, where each access is synchronized.

Modern applications usually use non-synchronized data structures such as ArrayList, HashMap, or StringBuilder – and the data structures optimized for multithreading in the java.util.concurrent package.

Because the code for biased locking is highly complex and deeply intertwined with the JVM code, it requires a great deal of maintenance and makes changes within the JVM's synchronization system costly and error-prone.

Therefore, the JDK developers decided in JDK Enhancement Proposal 374 to disable biased locking by default, mark it as "deprecated" in Java 15 and remove it entirely in one of the following releases.