Java中“对象引用”是栈中存储的堆内存地址值,非对象本身;它支持赋值和置null,但不可运算;分强、软、弱、虚四种,决定GC回收时机;==比较地址,equals需重写才比较内容。

Java 中的“对象引用”不是对象本身,而是一个指向堆中对象内存地址的变量值——它本质上是 JVM 为程序员提供的间接访问机制,类似 C 语言里的指针,但不可运算、不可直接解引用。
引用变量到底存的是什么
声明 String s = new String("hello") 时,s 这个变量存储的不是字符串内容,也不是整个对象,而是 JVM 在堆中分配出的那个 String 实例的内存地址(具体表现为一个由 JVM 管理的、不暴露给用户的句柄或直接指针)。
这个地址值可以被赋值、传递、置为 null,但不能做 +1、& 或强制类型转换等底层操作。
-
s是栈上的局部变量,占固定大小(通常 4 字节或 8 字节,取决于是否开启压缩指针) - 它所指向的
new String("hello")对象,完整结构(包括字符数组、哈希码、长度等)存在堆中 - 多个引用可指向同一对象,例如
String t = s后,s和t存的是同一个地址
四种引用类型的实际行为差异
Java 的 java.lang.ref 包定义了 StrongReference、SoftReference、WeakReference、PhantomReference,它们决定 GC 是否回收其指向的对象,而非影响访问语法。
立即学习“Java免费学习笔记(深入)”;
普通变量默认是强引用;其余三类需显式使用包装类:
SoftReferencesoftRef = new SoftReference<>(new byte[1024 * 1024]); WeakReference
-
StrongReference:只要引用链可达,GC 永远不回收 —— 这是造成内存泄漏的主因 -
SoftReference:内存不足时才回收,适合缓存(如图片缓存),但 JDK 8+ 回收策略更保守,不一定按“最近最少使用”清理 -
WeakReference:GC 时只要没强引用就立刻回收,ThreadLocal内部用它避免线程持有导致的内存泄漏 -
PhantomReference:无法通过它获取对象,仅用于在对象被回收后收到通知,必须配合ReferenceQueue使用
常见误判:== 和 equals 的混淆根源
两个引用用 == 比较,比的是地址值是否相同;而 equals() 默认行为也是 ==,只有重写后才可能比较内容。这是初学者最常踩的坑。
例如:
String a = "abc";
String b = "abc";
String c = new String("abc");
System.out.println(a == b); // true(字符串常量池优化)
System.out.println(a == c); // false(堆上新对象,地址不同)
System.out.println(a.equals(c)); // true(String 重写了 equals)- 不要依赖
==判断对象“内容相等”,除非你明确要判断是否是同一个实例 - 自定义类若需逻辑相等判断,必须同时重写
hashCode()和equals() - 注意
Integer等包装类在 [-128, 127] 范围内有缓存,Integer i = 100; Integer j = 100;时i == j为true,但超出范围就不可靠
引用和垃圾回收的边界容易被忽略
引用是否“可达”,不只看变量是否还活着,还要看从 GC Roots 出发能否找到该引用路径。局部变量超出作用域、方法执行完毕、引用被设为 null,只是让路径断裂的常见条件,但不是唯一条件。
比如:
- 静态集合类(如
static List)长期持有对象引用,会导致对象永远不可达回收 - 内部类隐式持有所属外部类的引用,若内部类对象被长期持有(如注册为监听器),外部类也无法被回收
- 使用
ThreadLocal后未调用remove(),在线程复用场景(如 Tomcat 线程池)下极易引发内存泄漏
真正难排查的,往往不是“引用没释放”,而是“引用还在,但你根本没意识到它还存在”。










