Java的四种引用类型按强度递减依次为：强引用、软引用、弱引用和虚引用。强引用确保对象不被回收；软引用在内存不足时回收，适合缓存；弱引用在GC时随时回收，用于避免内存泄漏；虚引用无法获取对象，仅与ReferenceQueue配合使用，用于对象回收前的资源清理，如释放直接内存。
在Java中，引用类型远不止我们日常代码里随处可见的那些对象引用那么简单。深入一点看，它们主要分为四种，它们各自扮演着不同的角色，也决定了对象在内存中的生命周期，以及垃圾回收器（GC）如何对待它们。这四种类型是：强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）和虚引用（Phantom Reference）。理解它们，对于我们优化内存使用、避免内存泄漏，甚至是处理一些底层资源管理，都至关重要。
解决方案
Java的这四种引用类型，从最强到最弱，逐步递减了对象被垃圾回收的“抵抗力”。
强引用 (Strong Reference)这是我们最常用、最直接的引用类型。比如 Object obj = new Object(); 这里的 obj 就是一个强引用。只要一个对象存在强引用，它就永远不会被垃圾回收器回收，即使内存空间不足，JVM也会抛出 OutOfMemoryError 错误。可以说，强引用是对象存活的“铁证”。
软引用 (Soft Reference)软引用比强引用弱一些。如果一个对象只有软引用，那么在系统内存不足时，它可能会被垃圾回收器回收。但如果内存充足，它会一直保留。这使得软引用非常适合实现内存敏感的缓存。你可以用 SoftReference softRef = new SoftReference(new T()); 来创建。当软引用指向的对象被回收后，softRef.get() 会返回 null。
弱引用 (Weak Reference)弱引用比软引用还要弱。它不会阻止垃圾回收器回收它指向的对象。也就是说，只要垃圾回收器运行，无论当前内存是否紧张，只要一个对象只有弱引用，它就会被回收。这听起来有点“无情”，但它在某些场景下非常有用，比如实现 WeakHashMap 或者处理监听器（listener）模式以避免内存泄漏。创建方式是 WeakReference weakRef = new WeakReference(new T());。同样，被回收后 weakRef.get() 返回 null。
虚引用 (Phantom Reference)这是最弱的引用类型，它甚至比弱引用还要弱。你无法通过虚引用来获取它指向的对象（phantomRef.get() 总是返回 null）。虚引用的唯一作用是，当它指向的对象被垃圾回收器回收时，会收到一个系统通知。它必须与 ReferenceQueue 结合使用。它的主要目的是跟踪对象被回收的状态，用于在对象被回收前进行一些清理工作，比如释放直接内存（Direct Memory）或文件句柄等非Java内存资源。
为什么Java需要这么多不同类型的引用？
我个人觉得，这其实是Java在自动内存管理（垃圾回收）和精细化内存控制之间找到的一种巧妙平衡。一开始接触Java，我们都觉得它“万事皆自动”，尤其是内存管理，不用像C++那样手动 new 和 delete。但很快就会发现，有些场景下，仅仅依靠强引用是远远不够的，甚至会导致问题。
比如说，你正在开发一个图片浏览器，需要缓存大量的图片。如果都用强引用，那用户一滑动，图片一多，很快就会 OutOfMemoryError。但如果用软引用，就能优雅地解决这个问题：内存不够了，GC会优先清理掉那些只被软引用指向的图片，给新图片腾出空间，用户体验会好很多。
立即学习“Java免费学习笔记（深入）”；
再比如，你在构建一个复杂的事件监听器系统。如果监听器对被监听对象持有强引用，那么即使被监听对象在业务上已经“死亡”了，只要监听器还存在，它就无法被回收，这会造成内存泄漏。这时候，如果监听器对被监听对象持有弱引用，那一旦被监听对象不再被其他地方强引用，它就能被正常回收，从而打破循环引用，避免泄漏。
虚引用则更像是“高级玩家”的工具，它提供了一种比 finalize() 方法更可靠、更可控的方式来管理JVM外部的资源。finalize() 的执行时机是不可预测的，甚至不保证执行，而虚引用配合 ReferenceQueue，则能让你在对象即将被回收的精确时机得到通知，从而及时地释放关联的非Java资源，这对于像NIO中的 ByteBuffer 这样的底层操作尤其重要。所以，这些不同类型的引用，其实是Java为了应对各种复杂的内存管理场景而提供的精细化工具箱。
软引用和弱引用在实际开发中如何应用？有什么区别？
这两种引用在实际开发中都挺有用的，但它们的“脾气”完全不同。
软引用（SoftReference），我通常会用它来构建那些“可有可无”的缓存。想象一下，你有一个需要从数据库加载大量数据的应用，或者一个需要显示大量图片的应用。你肯定不想每次都重新加载，所以会考虑缓存。
import java.lang.ref.SoftReference;import java.util.HashMap;import java.util.Map;public class ImageCache { private Map<String, SoftReference> cache = new HashMap(); public byte[] getImage(String imageUrl) { SoftReference softRef = cache.get(imageUrl); if (softRef != null && softRef.get() != null) { System.out.println("从缓存中获取图片: " + imageUrl); return softRef.get(); } // 缓存中没有或者已经被回收，重新加载 System.out.println("加载图片到缓存: " + imageUrl); byte[] imageData = loadImageFromDiskOrNetwork(imageUrl); // 模拟加载 cache.put(imageUrl, new SoftReference(imageData)); return imageData; } private byte[] loadImageFromDiskOrNetwork(String url) { // 模拟加载图片数据 return new byte[1024 * 1024]; // 1MB } public static void main(String[] args) { ImageCache imageCache = new ImageCache(); imageCache.getImage("http://example.com/img1.jpg"); imageCache.getImage("http://example.com/img2.jpg"); // 模拟内存紧张，触发GC System.out.println("尝试触发GC..."); System.gc(); // 提示GC，不保证立即执行 // 再次获取，如果内存紧张，可能需要重新加载 imageCache.getImage("http://example.com/img1.jpg"); }}
这段代码展示了一个简单的图片缓存。当内存吃紧时，JVM会优先回收那些只被软引用指向的图片数据，从而避免OOM。这对于那些对响应速度有要求，但又不能无限制占用内存的应用来说，简直是福音。
有道小P
有道小P，新一代AI全科学习助手，在学习中遇到任何问题都可以问我。
64 查看详情 
弱引用（WeakReference），它的应用场景就有点不一样了，它更关注的是“避免内存泄漏”。最经典的例子就是 WeakHashMap。
import java.lang.ref.WeakReference;import java.util.WeakHashMap;import java.util.Map;public class WeakRefExample { public static void main(String[] args) throws InterruptedException { // 示例1: WeakHashMap Map weakMap = new WeakHashMap(); MyKey key1 = new MyKey("KeyA"); MyKey key2 = new MyKey("KeyB"); weakMap.put(key1, "ValueA"); weakMap.put(key2, "ValueB"); System.out.println("WeakHashMap 初始大小: " + weakMap.size()); // 2 key1 = null; // 解除强引用 System.out.println("KeyA 的强引用解除。"); System.gc(); // 提示GC Thread.sleep(100); // 给GC一点时间 System.out.println("GC 后 WeakHashMap 大小: " + weakMap.size()); // 可能为1，KeyA被回收 // 示例2: 监听器模式 MyObject obj = new MyObject("监听对象"); MyListener listener = new MyListener(obj); // 监听器持有对象的弱引用 // 模拟其他地方不再持有MyObject的强引用 obj = null; System.gc(); Thread.sleep(100); // 理论上，MyObject应该被回收，listener内部的弱引用会失效 listener.checkObject(); // 应该输出 "监听的对象已被回收" } static class MyKey { String name; public MyKey(String name) { this.name = name; } @Override public String toString() { return "MyKey{" + name + "}"; } @Override public int hashCode() { return name.hashCode(); } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null || getClass() != obj.getClass()) return false; MyKey myKey = (MyKey) obj; return name.equals(myKey.name); } @Override protected void finalize() throws Throwable { System.out.println(name + " 被回收了。"); } } static class MyObject { String name; public MyObject(String name) { this.name = name; } @Override protected void finalize() throws Throwable { System.out.println(name + " 被回收了。"); } } static class MyListener { private WeakReference targetRef; public MyListener(MyObject target) { this.targetRef = new WeakReference(target); } public void checkObject() { MyObject target = targetRef.get(); if (target != null) { System.out.println("监听器还在监听: " + target.name); } else { System.out.println("监听的对象已被回收。"); } } }}
WeakHashMap 的键就是弱引用，这意味着如果键对象不再被其他地方强引用，它就会被GC回收，并且它在 WeakHashMap 中的对应条目也会随之消失。这在需要将元数据附加到对象上，但又不希望元数据阻止对象被回收时非常有用。在监听器模式中，如果监听器对被监听对象持有弱引用，那么当被监听对象不再被其他地方使用时，它就可以被正常回收，避免了传统监听器模式可能导致的内存泄漏。
区别：核心区别在于 回收时机。
软引用：只有在 内存不足 时才会被回收。它是一种“弹性”的缓存策略。弱引用：只要 GC运行，并且没有其他强引用指向它，就会被回收，无论内存是否紧张。它更像是一种“即用即弃”的策略，用于避免对象被不必要地“钉死”在内存中。
说白了，软引用是“我尽力保留，除非真没空间了”，而弱引用是“只要没人要我，GC一来我就走”。
虚引用真的有用吗？它和ReferenceQueue有什么关系？
虚引用，嗯，这东西初看确实有点让人摸不着头脑，因为它不能用来获取对象，那它还有什么用呢？它最大的用处，在于它提供了一种 “对象死亡通知” 的机制，而且这种通知是可靠的。它必须和 ReferenceQueue (引用队列) 配合使用。
当垃圾回收器准备回收一个对象时，如果发现这个对象存在虚引用，那么在回收之前，会把这个虚引用本身加入到与之关联的 ReferenceQueue 中。我们就可以通过轮询 ReferenceQueue 来得知某个对象即将被回收了。
这有什么用？最典型的场景就是 管理直接内存（Direct Memory） 或者其他 非Java堆内存资源。在Java中，我们有时候会通过JNI或者NIO的 ByteBuffer.allocateDirect() 来分配直接内存，这部分内存是不受JVM垃圾回收器直接管理的。如果Java对象（比如 ByteBuffer 实例）被回收了，但它对应的直接内存没有被释放，就会导致内存泄漏。
传统的做法可能会考虑 finalize() 方法来释放这些资源，但 finalize() 有很多缺点：执行时机不确定、不保证执行、可能导致性能问题。虚引用加 ReferenceQueue 就是为了解决这个问题而生的。
import java.lang.ref.PhantomReference;import java.lang.ref.ReferenceQueue;import java.nio.ByteBuffer;public class PhantomRefCleanup { public static void main(String[] args) throws InterruptedException { ReferenceQueue queue = new ReferenceQueue(); ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024 * 1024); // 分配1MB直接内存 // 创建一个虚引用，并关联到引用队列 PhantomReference phantomRef = new PhantomReference(directBuffer, queue); System.out.println("直接内存分配完成。"); // 解除对直接内存的强引用，使其成为可回收对象 directBuffer = null; System.out.println("解除 directBuffer 的强引用。"); // 启动一个线程来监控引用队列 Thread cleanerThread = new Thread(() -> { try { System.out.println("清理线程启动，等待虚引用进入队列..."); // 当虚引用指向的对象被回收时，虚引用自身会被加入到队列中 PhantomReference collectedRef = (PhantomReference) queue.remove(); System.out.println("虚引用进入队列，对象已被回收！可以执行资源清理操作了。"); // 在这里执行释放 directBuffer 对应的本地内存的操作 // 例如：sun.misc.Cleaner.clean(directBuffer); (实际操作更复杂，这里仅为示意) } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); cleanerThread.setDaemon(true); // 设置为守护线程，主程序退出时它也退出 cleanerThread.start(); System.out.println("尝试触发GC..."); System.gc(); // 提示GC // 等待清理线程完成 Thread.sleep(500); System.out.println("主线程结束。"); }}
在这个例子中，当 directBuffer 对象不再被强引用，并且被GC回收时，phantomRef 就会被加入到 queue 中。我们的清理线程通过从 queue.remove() 获取到这个虚引用，就知道对应的直接内存可以被安全地释放了。这比 finalize() 更可靠，因为它不依赖于JVM对 finalize() 的调度，而是直接与垃圾回收的生命周期挂钩。
所以，虚引用虽然不能直接用，但它和 ReferenceQueue 配合，为我们提供了一个在对象被回收前执行“临终遗言”的可靠机制，特别是在需要管理JVM外部资源时，它的价值就凸显出来了。这是一种非常底层但又非常强大的内存管理工具。
以上就是java 中都有哪些引用类型？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/566391.html
微信扫一扫 
支付宝扫一扫 
