设小reservedcodecachesize会触发jit硬性熔断，新方法退化解释执行致性能跌5–10倍；需监控jstat -compiler/-codecache及日志信号，按实测峰值上浮30%~50%设置，并启用usecodecacheflushing等防护。

保留代码缓存大小（-XX:ReservedCodeCacheSize）设小会直接触发 JIT 编译器“硬性熔断”——不是变慢，而是彻底停编。新方法（Lambda、Spring 代理、反射调用路径）全部退化为解释执行，性能常跌 5–10 倍。这不是 GC 问题，jstat -gc 看不出异常，线索全在编译器自身状态里。

盯住三个关键信号确认是否已熔断

别等服务卡顿再排查，要主动监控：

• jstat -compiler <pid></pid>：Compiled 字段长期不动，Failed 持续上涨（每分钟超 100 次即高危），Invalid 明显变大
• jstat -codecache <pid></pid>：Used 接近 Max，Unallocated Capacity 长期为 0；重点看 largest_free_block —— 若低于 1MB，即使 Used 只有 70%，JIT 也大概率已禁用
• 日志中出现 “CodeCache is full. The compiler has been disabled” 或 “hotspotcompilequeue: disabled”，这是熔断事实，不是警告

按实测峰值加余量设置 ReservedCodeCacheSize

不能拍脑袋定 512m 或 1g，得靠数据说话：

• 用 jstat -codecache <pid> 1000 5</pid> 每秒采样 5 次，抓高峰 Used 值
• 按峰值上浮 30%～50% 设定，例如峰值 180MB → 推荐 -XX:ReservedCodeCacheSize=256m（单位必须带小写 m）
• JDK 8u202 之前默认仅 48MB，老服务风险极高；JDK 11+ 默认 240–256MB，仍需实测
• 容器部署时，这部分内存要算进总预算，它属于 off-heap，不受 -Xmx 控制

只调大参数不够，必须组合防护

Code Cache 是连续内存块，盲目堆大会引发新问题：

• 设为 1G+ 容易触发 mmap 分配失败，尤其在容器内存受限时
• 过大缓存拖慢 JIT 内部 hash 表查找，反而降低编译吞吐
• 可能挤压 Compressed Class Space，诱发元空间 OOM
• 真正瓶颈常是碎片化：还有空闲字节，但最大连续空闲块趋近于 0

必须配合启用：

• -XX:+UseCodeCacheFlushing：在即将填满时主动驱逐冷代码
• -XX:+UseG1GC：对 Code Cache 元数据管理更友好，降低碎片概率
• -XX:CodeCacheMinimumFreeSpace=32m：设定安全水位线，提前触发清理

从源头减少 Code Cache 消耗

动态代理、Lambda、频繁 redefine 是主要“吃缓存大户”：

• Spring AOP 中避免无必要启用 proxy-target-class=true（即 CGLIB），优先用 JDK Proxy
• 禁止在循环或监听器中反复调用 Proxy.newProxyInstance 或 Enhancer.create
• 避免在循环内反复创建 Function 实例，改用静态方法引用
• 对高频反射调用（如 JSON 序列化）启用白名单缓存，减少 JIT 频繁重编译压力