Why Companies Still Use Java 8
Recently, I've been asking many friends about the Java versions they use in their projects. I found that a significant number of projects still run on Java 8, while some have moved to higher versions like Java 17 or Java 21. In these projects, choosing and tuning the garbage collector (GC) is a crucial part of optimizing application performance.
Many senior colleagues told me that around 80% of companies still use JDK 8. This is mainly because they choose between CMS and G1 based on memory requirements. In the current tech landscape, few new internet companies are emerging, and most prefer to stick with what they know to avoid increasing team workload and potential pitfalls.
From a Management Perspective
Optimization Benefits
Upgrading to newer Java versions (like Java 17 or Java 21) might bring performance improvements and support for new features. However, it's essential to weigh these benefits against the effort and risks involved in the upgrade process.
Workload and Risk
Upgrading requires adapting and testing existing code, which could introduce new issues. Management needs to assess whether the upgrade is necessary and prepare a technical feasibility analysis to report to higher-ups.
From a Developer's Perspective
Increased Workload
Upgrading means retesting all modules, which is time-consuming and labor-intensive. This can lead to conflicts between developers and management regarding workload and scheduling.
Technical Risks
Newer versions may have undiscovered compatibility or performance issues, adding uncertainty to the project.
Java 8 Garbage Collectors
Serial Garbage Collector (Serial GC)
Characteristics
Uses a single thread for garbage collection, causing all user threads to pause (Stop-The-World, STW) during GC.
Simple and efficient with no overhead from thread interactions.
Best for single-threaded environments or small applications.
Use Cases
According to the official documentation, if your application has a small dataset (up to around 100 MB) or runs on a single processor with no pause time requirements, you can use -XX:+UseSerialGC to select the Serial Collector.
Suitable for single-core CPU environments or resource-constrained scenarios.
Applications with low latency requirements and small datasets.
Parallel Garbage Collector (Parallel GC)
Characteristics
Uses multiple threads for garbage collection to reduce pause times.
Focuses on high throughput.
Use Cases
If peak application performance is the top priority and there are no pause time requirements or pauses of 1 second or longer are acceptable, use -XX:+UseParallelGC to select the Parallel Collector.
Suitable for multi-core processor environments.
Batch processing or big data processing scenarios.
CMS Garbage Collector (Concurrent Mark-Sweep GC)
Characteristics
Aims to minimize pause times using a concurrent mark-sweep algorithm.
The process includes initial mark, concurrent mark, remark, and concurrent sweep stages.
Best for applications sensitive to response times.
The CMS collector only works on the old generation and is based on the mark-sweep algorithm. Its operation consists of four steps:
Initial Mark (CMS initial mark)
Marks objects directly reachable from GC Roots. This stage is very quick and requires a brief STW pause.
Concurrent Mark (CMS concurrent mark)
Traces objects from GC Roots to mark live objects. This stage is time-consuming but runs concurrently with the application.
Remark (CMS remark)
Fixes any changes in object markings caused by the application's activity during the concurrent mark stage. This stage is slightly longer than the initial mark but still much shorter than the concurrent mark.
Concurrent Sweep (CMS concurrent sweep)
Clears the marked regions. This stage runs concurrently with the application.
Use Cases
If response time is more critical than overall throughput and GC pauses need to be kept under 1 second, consider using -XX:+UseConcMarkSweepGC or -XX:+UseG1GC.
Suitable for web applications, online transaction systems, and other latency-sensitive scenarios.
Large memory applications, but be aware of memory fragmentation issues. This can be mitigated by triggering CMS more frequently followed by a compacting collection.
G1 Garbage Collector (Garbage-First GC)
Characteristics
Divides the heap into regions and prioritizes garbage collection in regions with the most garbage.
Provides predictable pause times and reduces memory fragmentation.
Best for large memory and multi-core environments.
The G1 collection process is as follows:
Initial Marking (Initial Marking)
Marks objects directly reachable from GC Roots and adjusts the TAMS (Next Top at Mark Start) value to ensure new objects are created in the correct regions. This stage requires a brief STW pause but is very quick.
Concurrent Marking (Concurrent Marking)
Traces objects from GC Roots to identify live objects. This stage is time-consuming but runs concurrently with the application.
Final Marking (Final Marking)
Fixes changes in object markings caused by the application's activity during the concurrent marking stage. This stage requires a brief STW pause but can be executed in parallel.
Live Data Counting and Evacuation (Evacuation)
Sorts regions by their garbage collection value and cost, then evacuates objects based on the desired GC pause time. This stage can run concurrently with the application, and pausing user threads can significantly improve collection efficiency.
Use Cases
If your application fits the following criteria, consider migrating from CMS or ParallelOld to G1 for better performance:
More than half of the heap is occupied by live data.
Object allocation or promotion rates vary significantly.
You want to eliminate long GC pauses (over 0.5–1 second).
In practice, applications with 8 GB or more memory generally use the G1 garbage collector. Smaller memory sizes can lead to frequent GC cycles, which degrade performance.
Suitable for large applications requiring low latency and high throughput.
Ideal for e-commerce platforms, game servers, and other performance-critical scenarios.
Conclusion
While newer Java versions offer exciting features and improvements, many companies still rely on Java 8 due to its stability and familiarity. Garbage collector tuning remains a critical aspect of optimizing Java applications, and understanding the strengths and weaknesses of each collector is essential for making informed decisions.
Top comments (0)