Java中强、软、弱、虚引用本质是四种不同松紧度的对象持有方式：强引用阻止GC回收；软引用在内存不足时才被回收，适合缓存；弱引用在每次GC时都可能被回收，用于避免泄漏；虚引用无法获取对象，仅用于回收前通知，须配合ReferenceQueue使用。
Java里强、软、弱、虚引用的本质，是四种不同“松紧度”的对象持有方式——它们不改变你写代码的语法，但直接决定GC（垃圾回收器）会不会、什么时候、以什么优先级把对象收走。
强引用：只要它还“抓着”，GC就绝不动手
这是你每天都在用的默认行为：Object obj = new Object() 中的 obj 就是强引用。只要栈上或静态区还有变量直接指向这个对象，哪怕内存快爆了，JVM 宁愿抛 OutOfMemoryError 也不会回收它。
- 常见错误现象：缓存 Map 里长期存着大对象（如图片、JSON），又没手动清理，最终 OOM
- 使用场景：业务主对象、配置单例、Spring Bean 默认注入关系
- 容易踩的坑：忘记在监听器/回调注册后解绑，导致被强引用链锁死，引发内存泄漏
软引用：内存告急时才放手，适合做缓存
SoftReference —— 这个引用不会阻止 GC，但 GC 会“手下留情”，只在真正要 OOM 前才把它干掉。
- 关键机制：JVM 会按“最近最少使用”+“内存压力”综合判断是否回收，不是简单看引用类型
- 实操建议：不要依赖
softRef.get()必然返回非 null；每次取值前必须判空，且做好重建逻辑 - 性能影响：频繁创建/释放软引用对象会增加 GC 扫描开销；高并发下建议配合
ReferenceQueue异步清理，避免阻塞主线程
弱引用：GC 一来就消失，适合临时绑定和自动清理
WeakReference —— 只要一次 GC 触发，不管内存多富裕，这个引用指向的对象大概率就没了。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 典型应用：
WeakHashMap的 key 就是弱引用；注册监听器时用弱引用可避免 Activity/Fragment 泄漏 - 注意点：不能用于需要稳定生命周期的场景；
get()返回 null 是常态，不是异常 - 陷阱：别在构造弱引用后还保留强引用（比如同时把对象赋给另一个变量），否则弱引用形同虚设
虚引用：拿不到对象，只等“死亡通知”
PhantomReference —— 调用 phantRef.get() 永远返回 null，唯一作用是让对象在被回收前“路过”一次 ReferenceQueue。
- 为什么不用 finalize()？因为虚引用不阻塞 GC，而
finalize()已废弃且严重拖慢回收速度 - 实操必需项：必须搭配
ReferenceQueue使用；需另起线程轮询队列，执行资源释放（如关闭文件句柄、释放堆外内存） - 容易忽略的细节：虚引用对象进入队列 ≠ 已回收，只是“已标记为待回收”；真正的内存释放发生在后续 GC 阶段
真正难的不是记住四类引用的定义，而是判断：当前对象该不该被“保命”、能活多久、谁负责善后。强引用是默认保险带，软/弱是弹性缓冲，虚引用则是临终遗嘱执行人——选错类型，轻则缓存失效，重则内存雪崩。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
