弱引用在每次GC时立即回收，与内存水位无关；软引用仅在OOM风险时才回收，依据堆剩余空间和创建时间决策。二者触发时机、回收条件和设计意图根本不同，导致缓存场景下出现明显性能断层。
弱引用和软引用在堆内存水位逼近临界点时，行为差异非常明确——不是“程度轻重”的区别，而是触发时机、回收条件和设计意图的根本不同。这种差异直接导致它们在缓存场景下的性能表现出现明显断层。
弱引用：不看水位，只看GC轮次
弱引用对象的生命周期完全由GC执行节奏决定，与当前堆内存使用率无关。只要JVM启动一次GC（无论是Minor GC还是Full GC），所有仅被弱引用持有的对象都会被立即回收。
- 哪怕堆内存使用率只有40%，一次Young GC也会清掉所有WeakReference指向的对象
- 它不参与任何“内存压力感知”，也不等待OOM前的抢救式回收
- 典型用途是构建“瞬时映射”——比如ThreadLocalMap中的key、WeakHashMap的键，目标是避免强引用导致的泄漏，而非缓存保活
软引用：紧盯水位，为OOM兜底让路
软引用的回收逻辑绑定在JVM的内存压力判断上，核心依据是“是否即将触发OutOfMemoryError”。它不会在每次GC都响应，而是在GC判定“再不回收就要OOM”时才批量清理。
- HotSpot中，软引用默认保留到最近一次GC后仍存活，并在后续GC中根据堆剩余空间和软引用创建时间综合决策
- 可通过-XX:SoftRefLRUPolicyMSPerMB调整“每MB空闲堆可保留软引用毫秒数”，影响其滞留时长
- 适合做图片、模板、解析结果等“可重建但代价较高”的缓存——内存宽裕时全留，紧张时渐进释放，避免突兀失效
性能断层来自策略错位
当堆水位持续攀升至90%+，弱引用缓存会频繁失效率飙升（每次GC都清），而软引用缓存仍保持稳定命中，直到最后一次Full GC前才集中淘汰。这种“弱引用提前雪崩、软引用延迟缓冲”的现象，就是典型的性能断层：
- 弱引用缓存：高频率GC → 高频重建 → CPU和IO负载陡增 → 响应毛刺明显
- 软引用缓存：命中率平滑下降 → 资源释放可控 → 系统退化更线性，用户体验更平稳
- 误用弱引用替代软引用做业务缓存，常导致服务在内存压力初期就出现性能拐点
简单说：弱引用是“GC一来就走”，软引用是“OOM之前才走”。盯住这个分水岭，就能避开多数缓存抖动和OOM连锁问题。
