提到JDK源码，很多人的第一反应往往是“太高深了，平时写业务代码根本用不上”。直到某天面试官随口问一句“Object类里的方法你了解多少”，你才惊觉Java世界里最底层的那块基石，恰恰是最容易被忽略的角落。Object类，所有Java类的根，JDK源码中保存最完好的古老类之一，里面的方法数得过来，可每一个都承载着JVM运行时的核心约定，也是理解并发、容器、反射、垃圾回收的起点。今天不聊虚的，我把JDK里Object类的源码翻出来，一行一行带你看，从设计逻辑到实战落点，把那些天天在用却从未细想的细节一次补全。

1. 从根开始：Object在JDK中的位置与设计哲学

1.1 为什么所有类都隐式继承Object

先说一个很多人忽略的事实：Java里的类如果没有显式指定父类，编译器会自动让它继承Object。这不是IDE的补全，而是JVM规范层面的约定。所有类最终都能调用toString、equals、hashCode、wait、notify这些方法，根源就在这层隐式继承上。

但更深的问题值得想一下：为什么Java要设计这样一个“万类之根”？

这要从JVM的类型体系说起。有了Object作为公共父类，JVM在运行时才能用统一的方式处理所有对象引用。比如你写一个方法，参数类型是Object，那任何引用类型都能传进来；你创建数组，Object[]能装下所有引用对象。Java的类型系统因此获得了极大的灵活性，而这种灵活性的物质基础，就是Object这个“宇宙大爆炸奇点”。

从源码角度切入，更能看清这个类的分量。JDK9以后，Java改成模块化结构，Object类被放在java.base模块的java.lang包下。这是全JDK里最基础的一个包，任何Java程序启动时，java.base模块必然被加载，而Object类又是类加载阶段最早被初始化的类之一。可以这么理解：整个JVM在“开工”之前，必须先把Object“安顿”好。

1.2 一张源码全貌：Object类到底定义了哪些方法

打开JDK源码中java/lang/Object.java，整套源码其实只有不到300行。去掉注释和空行，真正的方法声明就那11个左右。别看少，每一个都是重量级的。

注意到关键信息了吗？这些方法的注释特别有意思，比如wait(0)表示永久等待，hashCode的注释还专门提了“不需要保证不同对象返回不同哈希值”这一约束。

源码的排版也非常讲究。像wait(long timeout)的几个重载，注释占了绝大多数篇幅，方法体只有一行调用native方法。为什么这么设计？因为平台相关。JVM需要调用操作系统底层的线程调度能力，而各个操作系统的实现机制不同，Java用native方法把这块差异隔离掉，上层代码看到的永远是同一个API。这就是JNI的早期智慧。

2. 重写率最高的三个方法：equals、hashCode与toString的源码解读

2.1 equals：从源码看“引用相等”与“逻辑相等”的分水岭

Object类里equals的源码极其直白，就一行：

public boolean equals(Object obj) { return (this == obj); }

==比较的是引用地址，所以Object的默认实现只做“引用相等”判断。这样设计是合理的：如果没有明确的重写规则，两个对象只有是同一个对象时才相等。这也是开口闭口“equals和==到底啥区别”的根本依据。

问题在于，业务世界里我们想要的往往是“逻辑相等”。两个User对象，只要id相同，就应该是同一个用户。这时就必须重写equals。源码里注释其实已经把重写规范写得很清楚了：反身性、对称性、传递性、一致性，以及“equals相等时hashCode一定要相等”。

有意思的是，很多人背过这些规则，却不知道它们是从Object源码注释里来的。我建议每个Java开发者都去认真读一遍Object类源码里那几段注释，里面不只讲了规范，还给出了反例。比如对称性问题：A类里的equals只要遇到B类就直接返回false，B类里又对A类特殊处理返回true，这时候a.equals(b)和b.equals(a)结果不一致，集合类里就会冒出各种诡异问题。

2.2 hashCode：native方法背后的身份哈希与对象布局

hashCode的源码同样只有一行，真正的实现在JVM内部：

public native int hashCode();

它返回的是对象的哈希值，但这里有个关键细节：Object的默认hashCode并不是对象的内存地址，而是JVM基于对象头生成的一个“身份哈希值”。HotSpot虚拟机里，这个值通常被缓存在对象头的mark word中。也就是说，一个对象在第一次计算hashCode之后，这个值就会被记录下来，之后哪怕GC搬移了对象位置，hashCode也不会变。

这个设计直接影响HashMap的实现。HashMap计算桶位置时依赖hashCode()，如果对象位置一变哈希值就变，那整个哈希表就全乱了。所以JVM很聪明地把身份哈希值固化在对象头里，跟对象“死绑”。

还有一个容易被忽视的点：如果类重写了hashCode，它就不再是身份哈希了。所以你在调试时看到的“形如8a5b0d”的十六进制值，如果你重写了hashCode，就不再是对象头的身份哈希值，而是你自定义逻辑计算的结果。很多人在排查问题时把这两者搞混，导致误判。遇到这种情况，可以去读System.identityHashCode的文档，这个方法会绕过重写，直接拿到对象原始的身份哈希值。

2.3 toString：默认实现为什么是“类名@十六进制”

toString的源码也非常短：

public String toString() { return getClass().getName() + "@" + Integer.toHexString(hashCode()); }

也就是“全限定类名@无符号十六进制哈希值”。它的意图是提供一个“可打印的对象标识”，让你一眼分辨对象是哪个类、大致是什么身份。

注意这里用的是getClass().getName()而不是Object.class.getName()，因为getClass()返回的是运行时实际类型。哪怕父类里定义了toString，只要子类没有重写，拼出来的依然是子类的全限定名。这一点和Java的动态绑定机制是呼应的。

实际开发中，toString往往承担着日志打点的责任。我见过不少项目在日志里直接打印对象，如果没有重写toString，输出就是一堆“com.example.User@1a2b3c4”，除了能区分是不是同一对象之外毫无业务价值。所以但凡要打印的对象，我强烈建议用IDEA或者Lombok生成一套合理的toString实现，把关键字段放进去，这样排查问题效率直接翻倍。

3. 并行逃不开的等待机制：wait/notify为什么挂在Object上

3.1 把wait/notify放在Object里的设计逻辑

这是很多Java开发者在读源码时最想问的问题：为什么wait/notify要放在Object里，而不是Thread里？

答案是：Java的锁是“对象级”的，不是“线程级”的。在JVM的同步机制里，每个对象都可以关联一个监控器（Monitor），线程进入synchronized代码块时，本质上是去获取那个对象的Monitor所有权。所以等待和唤醒操作也必须围绕对象展开，而不是告诉某个线程“你先停一下”。

用生活化的例子来理解：synchronized的锁像是房子的钥匙，多个线程抢同一把钥匙才能进门。而wait就像是屋里的人在等一个外部条件，他不可能“叫另一个线程停下来等他”，只能在这个房子的钥匙上登记“我在等”，然后交还钥匙出去等。notify则像是在门外喊一声“有条件的可以进来了”，唤醒在这个钥匙上登记过的线程。

把wait/notify放在Object上，正好让“锁”和“等待条件”在逻辑上统一起来。这也是为什么wait/notify只能在持有Monitor（也就是在synchronized块或方法里）时调用，否则会抛IllegalMonitorStateException。源码注释里已经写得很明白：调用wait会把当前线程加入对象的wait set，并释放对象的锁。

3.2 从monitor层看wait/notify的底层流转

虽然Object源码里的wait方法都只是native声明，但HotSpot虚拟机的实现路径是可以追的。字节码层面，进入synchronized时执行monitorenter，退出时执行monitorexit，每个对象关联一个ObjectMonitor，它内部维护着一个等待队列和一个唤醒队列。

wait的底层行为可以拆成三步：把当前线程封装成ObjectWaiter节点，加入Monitor的_WaitSet；释放当前线程持有的Monitor；然后线程进入阻塞状态，直到被唤醒。

notify则是从_WaitSet里挑一个线程（注意，是挑一个，不是挑特定优先级最高的，具体策略JVM实现各有差异），把它转移到另一个队列，让它在锁被释放后重新竞争。如果用的是notifyAll，那就是把_WaitSet里所有线程都转移到竞争队列。

这个底层机制解释了为什么Java官方一直强调“在循环里使用wait，不要用if”。因为notify只会唤醒一个线程，而且线程唤醒后还要重新争夺锁，抢不到锁还得继续阻塞。更麻烦的是，某些场景下会有“虚假唤醒”——线程可能在没有通知的情况下被唤醒。如果不把条件判断放进循环，线程醒来很可能发现条件根本没满足，然后误操作。这是并发编程里极其隐蔽的坑。

4. 从源码到实战：Object方法在项目里的正确打开方式

4.1 重写equals/hashCode的正确姿势与工具链

读源码是为了少踩坑。equals和hashCode重写率最高，也最容易出错。

先给出一个比较稳妥的写法，这里以User类为例：

public class User { private Long id; private String username; @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; User user = (User) o; return Objects.equals(id, user.id) && Objects.equals(username, user.username); } @Override public int hashCode() { return Objects.hash(id, username); } }

这套代码有几点讲究：首先用getClass() != o.getClass()判断兼容类型，防止父子类之间进行不对称比较；其次用Objects.equals做字段比较，顺便处理了null的情况；最后hashCode用Objects.hash统一计算，保证equals相等的对象hashCode也相等。

实际项目里我很少手写这套逻辑。IDEA的Generate equals and hashcode功能已经做得非常成熟，会自动引入Objects.equals和Objects.hash。而Lombok的@EqualsAndHashCode更省事，但要注意它会默认包含非static且非transient的字段，如果不想让某个字段参与比较，要用@EqualsAndHashCode.Exclude注解标明。

这里说一个易踩的坑：一旦重写了equals，几乎必须同时重写hashCode。原因是一个对象如果被放进HashSet或HashMap，集合类先通过hashCode定位桶，再通过equals确认相等。如果只重写equals，两个逻辑相等的对象hashCode不同，就可能被放进不同的桶，集合里出现“重复对象”。这种问题不会立刻报错，但会让你排查到崩溃。

4.2 finalize的消亡与Cleaner/GC替代方案

Object源码里的finalize方法堪称“最被高估的API”之一。它在对象被GC回收前被调用，初衷是给开发者一个清理外部资源的钩子。但实际使用中问题太多：触发时机不确定，JVM不会保证finalize一定执行，甚至可能出现对象在finalize里“复活”的诡异情况。

源码注释明确标注了@Deprecated(since = "9")，以下是JDK 11中的呈现状态：

@Deprecated(since = "9") protected void finalize() throws Throwable { }

JDK 9开始，这个方法的废弃标记就写在了源码里。原因也不难理解，Finalizer线程会保存所有重写了finalize的对象引用，导致它们至少经过两次垃圾回收才能被真正回收，这本身就是对内存回收的干扰。更糟的是，顺序不可控，依赖它做资源释放，等于把命运交给不确定因素。

替代方案是按需使用AutoCloseable配合try-with-resources，或者使用Cleaner机制。Cleaner是JDK 9引入的，可以注册一个清理动作，在对象被GC回收前回调。它的优势在于不持有对象的强引用，不会阻碍垃圾回收。但注意，Cleaner的回调也不是“马上发生”的，它做了异步处理，本质上是尽力而为。真正的良策仍然是“主动关闭”：数据库连接用完就关，文件流用完就关，线程池用完就shutdown。源码能给你解释底层机制，但替代不了你写的健壮代码。

4.3 用wait/notify写一个“线程交替打印”的经典案例

要说Object里wait/notify在实战中的应用，最经典的例子是“两个线程交替打印奇偶数”。直接用最裸的wait/notify写一次，能让你真正理解等待-通知模型：

public class PrintOddEven { private static final Object lock = new Object(); private static int count = 1; private static final int MAX = 100; public static void main(String[] args) { Thread odd = new Thread(() -> { while (count < MAX) { synchronized (lock) { if (count % 2 == 0) { try { lock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } else { System.out.println(Thread.currentThread().getName() + ": " + count++); lock.notify(); } } } }, "odd"); Thread even = new Thread(() -> { while (count < MAX) { synchronized (lock) { if (count % 2 == 1) { try { lock.wait(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } else { System.out.println(Thread.currentThread().getName() + ": " + count++); lock.notify(); } } } }, "even"); odd.start(); even.start(); } }

这段代码有几个关键点：wait必须放在循环里，因为线程被唤醒后不一定能立刻满足条件；wait和notify必须在持有同一把锁的代码块内调用；还有一点容易被忽略——InterruptedException这里不能只吞掉，设置为中断标记是更稳妥的处理方式。

实际跑下来你会发现，逻辑是对的，但如果生产环境里让你用这种方式处理复杂任务协调，那简直是在刀尖上跳舞。JDK 5之后，java.util.concurrent包提供的ReentrantLock、Condition、CountDownLatch、CyclicBarrier等工具已经把这些底层操作封装得非常好，优先级更高。学习wait/notify的意义在于理解并发模型的底层原理，真正开发时还是优先用并发包。

5. 常见问题与排查技巧实录

5.1 Object面试高频拷问速查表

在面试和实际交流中，围绕Object源码展开的问题非常固定，我把接触过的高频问题整理成了一张速查表。

这个表最大的价值不是背答案，而是让人明白：这些问题背后都是源码里的明确逻辑，不是面试官随口发明出来的。

5.2 本地快速阅读JDK源码的配置方法与踩坑

既然要读源码，环境就很重要。很多人下载了JDK之后，在IDEA里点进Object类看到的却是“Sources not found”，这是因为安装时只装了运行时包，没有附带src.zip。解决方式有两种。

第一种，重新下载带源码的完整JDK包。大部分发行版在jdk路径/lib/src.zip下都会有源码压缩包，比如OpenJDK发行版的目录里常见lib/src.zip。IDEA会自动关联它。如果IDEA仍提示找不到源码，可以在Project Structure的SDK配置里手动指定src.zip路径。

第二种，用Maven仓库里的源码包。如果你的项目用的是Maven，可以直接依赖jdk源码包或下载OpenJDK源码。但我觉得最顺手的是直接在IDEA里操作：File -> Project Structure -> SDKs -> Sourcepath，把源码压缩包路径加进去，然后重新打开Object类，就能看到完整的源码和注释了。

这里说一个容易忽略的细节：查看源码时，如果看到的是“反编译”结果而不是原始源码，别慌，那说明你本地没有源码jar包，IDEA自动用了反编译插件。反编译结果通常没有原始注释，而Object类最有价值的恰恰是那些大段注释。配置好源码路径后，一定要认准真正的src.zip内容。

另一个常见的坑是：给IDEA配置JDK时选错了版本。比如机器上装了多个JDK，配置时误选了JRE目录，导致源码匹配不上。我建议在Project Structure里明确指定具体的JDK主目录，比如/usr/lib/jvm/java-17-openjdk-amd64，避免混用。

我自己的做法是单独准备一份“源码阅读专用”的OpenJDK副本，目录路径不放在系统默认位置，避免和其他工具链冲突。这样在阅读源码时，版本可控，路径清晰，排查问题也方便。

最后分享一个个人经验：读Object类源码时，千万别只盯方法签名，它的注释才是精华中的精华。Object类的注释几乎是一篇微型Java规范，涵盖了方法的重写契约、异常触发条件、并发注意事项。我当年是在看了几次wait(0)的注释后才彻底搞懂“0代表无限等待”这个细节的。后来排查一个“线程卡死”问题，靠的就是对wait(long timeout)语义的理解——超时时间为0不是立即返回，而是永久等待。这种细节，说明书和面试题很少讲透，只有亲自打开源码，才能真正沉淀成自己的知识。