Java软引用与GC的作用及Jenkins G1GC参数调优疑问

Hey there, let's unpack your questions about this JVM parameter and your Jenkins setup with G1GC:

1. What does the default value 1000ms mean, and what's the threshold here? #

The -XX:SoftRefLRUPolicyMSPerMB parameter controls how long soft reference objects can stay in memory before the JVM considers them eligible for garbage collection.

The default 1000ms/MB translates to: for every 1MB of free heap memory remaining, soft reference objects can survive an additional 1000 milliseconds (1 second).

The "threshold" here is a dynamic calculation tied to your current free heap space. For example:

• If you have 5MB of free heap, soft references can live up to 5 seconds after they become unreachable
• If free heap drops to 1MB, that window shrinks to just 1 second
• When heap is nearly full (free MB approaches 0), the allowed survival time plummets, making soft references get cleaned up almost immediately to avoid OOM.

2. My Jenkins has soft references taking up 80% of heap (observed via HProf) #

That's a clear sign your current soft reference retention policy is too lenient. Soft references are often used for caching (like Jenkins storing build artifact metadata, plugin caches, etc.), but when they're hogging 80% of your heap, it means the JVM isn't cleaning them up fast enough as memory gets tight. This is a major red flag for impending OOM errors if your Jenkins workload grows or heap space gets constrained.

3. What happens if I lower the value to 10ms with G1GC? #

Lowering -XX:SoftRefLRUPolicyMSPerMB to 10ms will make the JVM aggressively reclaim soft reference objects much sooner:

• The upside: You'll free up heap space far more quickly when memory is low, drastically reducing the risk of OOM errors. For your case where soft refs are 80% of heap, this should immediately alleviate memory pressure.
• The potential downside: Since soft references are often used for caching, faster cleanup means those cached objects will need to be recreated more frequently. This could lead to a slight increase in CPU usage (as Jenkins rebuilds cached data) and maybe minor slowdowns in some operations (like loading build history pages or plugin dashboards).

But with G1GC, this tradeoff is usually manageable. G1GC is optimized for low-latency garbage collection, so the overhead of recreating soft reference objects is likely to be minimal compared to the benefit of avoiding OOM crashes. I'd recommend making the change, then monitoring key metrics:

• Heap usage trends
• GC pause times and frequency
• Jenkins response times for common operations

内容的提问来源于stack exchange，提问作者Coder