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<T> softRef = new SoftReference<>(new T()); 来创建。当软引用指向的对象被回收后,softRef.get() 会返回 null。
弱引用 (Weak Reference)
弱引用比软引用还要弱。它不会阻止垃圾回收器回收它指向的对象。也就是说,只要垃圾回收器运行,无论当前内存是否紧张,只要一个对象只有弱引用,它就会被回收。这听起来有点“无情”,但它在某些场景下非常有用,比如实现 WeakHashMap 或者处理监听器(listener)模式以避免内存泄漏。创建方式是 WeakReference<T> weakRef = new WeakReference<>(new T());。同样,被回收后 weakRef.get() 返回 null。
虚引用 (Phantom Reference)
这是最弱的引用类型,它甚至比弱引用还要弱。你无法通过虚引用来获取它指向的对象(phantomRef.get() 总是返回 null)。虚引用的唯一作用是,当它指向的对象被垃圾回收器回收时,会收到一个系统通知。它必须与 ReferenceQueue 结合使用。它的主要目的是跟踪对象被回收的状态,用于在对象被回收前进行一些清理工作,比如释放直接内存(Direct Memory)或文件句柄等非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<byte[]>> cache = new HashMap<>();
public byte[] getImage(String imageUrl) {
SoftReference<byte[]> 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。这对于那些对响应速度有要求,但又不能无限制占用内存的应用来说,简直是福音。
弱引用(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<MyKey, String> 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<MyObject> 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一来我就走”。
虚引用,嗯,这东西初看确实有点让人摸不着头脑,因为它不能用来获取对象,那它还有什么用呢?它最大的用处,在于它提供了一种 “对象死亡通知” 的机制,而且这种通知是可靠的。它必须和 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<ByteBuffer> queue = new ReferenceQueue<>();
ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024 * 1024); // 分配1MB直接内存
// 创建一个虚引用,并关联到引用队列
PhantomReference<ByteBuffer> phantomRef = new PhantomReference<>(directBuffer, queue);
System.out.println("直接内存分配完成。");
// 解除对直接内存的强引用,使其成为可回收对象
directBuffer = null;
System.out.println("解除 directBuffer 的强引用。");
// 启动一个线程来监控引用队列
Thread cleanerThread = new Thread(() -> {
try {
System.out.println("清理线程启动,等待虚引用进入队列...");
// 当虚引用指向的对象被回收时,虚引用自身会被加入到队列中
PhantomReference<ByteBuffer> collectedRef = (PhantomReference<ByteBuffer>) 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 中都有哪些引用类型?的详细内容,更多请关注php中文网其它相关文章!
java怎么学习?java怎么入门?java在哪学?java怎么学才快?不用担心,这里为大家提供了java速学教程(入门到精通),有需要的小伙伴保存下载就能学习啦!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号