The garbage collection (GC) mechanism is responsible for freeing up memory occupied by unused objects, allowing the system to recycle resources. However, improper GC configuration can lead to frequent Full GCs, increased application latency, and decreased throughput. Therefore, in production environments, analyzing memory usage through GC logs is essential for targeted optimization. Ubuntu provides developers with an excellent environment for collecting and analyzing GC logs. Combined with appropriate JVM parameters and system optimizations, this can ensure stable Java applications in high-concurrency and large-scale data scenarios.

When launching a Java application, you can enable GC logging to record memory changes and collections. For example:

java -Xms1g -Xmx1g -XX:+UseG1GC -Xlog:gc*:gc.log -jar app.jar

The above command specifies a heap size of 1GB, uses the G1 garbage collector, and outputs GC logs to the gc.log file. For JDK 8, you can use:

java -Xms1g -Xmx1g -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -jar app.jar

This will capture detailed GC events, timestamps, heap size changes, and other information.

After collecting the logs, you can analyze them by viewing the text directly. A typical GC log snippet is as follows:

2025-08-29T12:00:15.123+0000: 45.678: [GC pause (G1 Evacuation Pause) (young), 0.0456789 secs]
[Parallel Time: 30.0 ms, GC Workers: 8]
[Eden: 512.0M(512.0M)->0.0B(512.0M) Survivors: 64.0M->64.0M Heap: 1024.0M(1024.0M)->512.0M(1024.0M)]

This log shows a G1 young generation collection, which took approximately 45 milliseconds. The Eden space occupied 512MB before the collection and was cleared afterward, reducing the total heap usage from 1024MB to 512MB. This information can be used to determine whether GC pause time and heap space usage are appropriate.

If an application frequently triggers Full GC during operation, for example, once every minute, this indicates insufficient memory allocation or inadequate object lifecycle management. In this case, you need to increase the heap space or optimize the code to reduce the frequent creation of large objects.

java -Xms2g -Xmx2g -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=45 -Xlog:gc*:gc.log -jar app.jar

Increasing the heap space and adjusting the threshold for triggering GC can delay the occurrence of Full GC.

For more intuitive analysis of GC logs, tools can be used. Graphical tools such as gceasy.io and GCViewer can parse logs and generate reports that include information such as throughput, pause time distribution, and memory usage trends. In Ubuntu, simply upload the gc.log file to obtain complete analysis results.

During the tuning process, it is important to select an appropriate garbage collector based on the application's characteristics. For low-latency scenarios, consider using G1 or ZGC. For batch processing tasks requiring higher throughput, use Parallel GC. For example:

java -Xms4g -Xmx4g -XX:+UseParallelGC -Xlog:gc*:gc.log -jar batchApp.jar

This configuration is suitable for long-running big data computing programs and can improve overall throughput.

In Ubuntu, system-level monitoring is also necessary. Use top or htop to view the CPU and memory usage of the Java process in real time, and use vmstat to monitor system-level memory pressure. If the Java process is consistently approaching the system memory limit and the GC log shows frequent GCs, it indicates that you need to expand hardware resources or adjust the off-heap memory configuration. For example, to set Direct Memory:

java -XX:MaxDirectMemorySize=1g -Xmx2g -jar nettyApp.jar

Avoid application jitter caused by insufficient off-heap memory.

When tuning GC, it's also important to consider latency targets. The G1 garbage collector allows you to set the desired maximum pause time using the MaxGCPauseMillis parameter:

java -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xlog:gc*:gc.log -jar webApp.jar

This means that GC pauses are minimized to 200 milliseconds. In web applications or cross-border e-commerce systems, this tuning can significantly improve user experience.

In actual production environments, the tuning process typically involves enabling GC logging and collecting data for a period of time. Tools are then used to analyze data to determine whether there are frequent Full GCs, excessively long GC pauses, or signs of memory leaks. The heap size, generation ratio, and garbage collector type are then adjusted accordingly. The system is run again, and new logs are collected for comparison until optimal performance is achieved.

In short, analyzing Java GC logs and performing tuning in Ubuntu is a systematic process that requires a deep understanding of the JVM memory model and garbage collection mechanism, as well as repeated verification based on specific business scenarios. By properly configuring the heap size, selecting an appropriate GC algorithm, adjusting the trigger threshold, and using tools for log analysis, developers can effectively reduce the performance impact of GC, ensuring that Java applications remain stable and efficient in high-concurrency environments.