JVM的JIT CodeCache回收时机咨询及CodeCache满问题求助

Great question—let's break down exactly when CodeCache gets recycled in your specific JDK version, and tie it directly to the error you're seeing.

First, a critical detail for JDK 7: CodeCache does NOT automatically recycle by default. Unlike JDK 8 and later, where CodeCache flushing is enabled out of the box, Oracle JDK 7 keeps this feature turned off. That means once the JIT compiler stores compiled code in CodeCache, it stays there permanently unless you explicitly enable the flushing mechanism.

When CodeCache will recycle (once you enable it) #

To get CodeCache to free up unused space, you need to add this JVM parameter first:

-XX:+UseCodeCacheFlushing

With this flag enabled, the JVM will trigger a flush in two key scenarios:

• When CodeCache usage hits 90% capacity
  The JVM tracks how much of your configured ReservedCodeCacheSize is in use. Once it crosses the 90% threshold, it scans for code that's no longer needed—like compiled code from classes that have been fully unloaded by the garbage collector, or less frequently run ("non-hot") code that's unlikely to execute again. It discards these to free up space.
• Emergency flush when CodeCache is full and compiler is disabled
  If you hit that warning saying Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled., the JVM will attempt an emergency flush to reclaim space. If successful, it will re-enable the JIT compiler—but by this point, your app has already been running in slow interpreted mode, which explains the performance hit.

Fixes to prevent your issue from recurring #

Since you've already bumped ReservedCodeCacheSize to 256M, here are a few more steps to lock this down:

• Add -XX:+UseCodeCacheFlushing immediately—this is the most important change to enable automatic recycling and stop CodeCache from filling up permanently.
• Monitor CodeCache usage with -XX:+PrintCodeCache—this prints usage stats when the JVM starts and shuts down. For real-time visibility, use tools like JConsole or VisualVM to track how CodeCache grows over time.
• Check for dynamic class generation—if your app uses proxies, bytecode enhancers, or reflection-heavy libraries, make sure those dynamically created classes are being properly unloaded by the GC. If they're stuck in memory, their compiled code will clog CodeCache even with flushing enabled.
• Tweak flush thresholds (optional)—you can adjust when flushing happens with -XX:CodeCacheMinimumFreeSpace (sets the minimum free space the JVM tries to maintain; default is 500KB) or control how CodeCache expands with -XX:CodeCacheExpansionSize.

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