提到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个左右。别看少每一个都是重量级的。方法签名修饰符核心作用getClass()native、final返回运行时类对象hashCode()native返回对象哈希值equals(Object obj)普通方法比较对象相等性clone()native、protected创建并返回对象副本toString()普通方法返回对象字符串表示notify()native、final唤醒一个等待线程notifyAll()native、final唤醒所有等待线程wait(long timeout)native、final让当前线程等待wait(long timeout, int nanos)普通方法带纳秒精度的等待wait()final无限期等待finalize()protected被废弃的回收钩子注意到关键信息了吗这些方法的注释特别有意思比如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类就直接返回falseB类里又对A类特殊处理返回true这时候a.equals(b)和b.equals(a)结果不一致集合类里就会冒出各种诡异问题。2.2 hashCodenative方法背后的身份哈希与对象布局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.User1a2b3c4”除了能区分是不是同一对象之外毫无业务价值。所以但凡要打印的对象我强烈建议用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源码展开的问题非常固定我把接触过的高频问题整理成了一张速查表。问题核心答案源码依据为什么所有类都要继承Object提供统一的类型体系和公共方法入口java.base模块的根类约定equals和有什么区别比较引用地址equals默认也是引用比较重写后可以比较内容equals源码的this obj为什么重写equals必须重写hashCode集合类依赖hashCode定位和equals确认hashCode与equals的契约注释wait和sleep有什么区别wait释放锁sleep不释放锁wait依赖对象监视器wait的native实现与sleep的Thread方法分离notify和notifyAll怎么选单消费者用notify多消费者用notifyAll避免唤醒目标不明确ObjectMonitor的等待队列组织方式finalize为什么被废弃时机不可控影响GC容易引发资源泄漏JDK9的Deprecated标记Object可以作为锁吗可以但不推荐公共对象被锁范围过大每个对象都有Monitor这个表最大的价值不是背答案而是让人明白这些问题背后都是源码里的明确逻辑不是面试官随口发明出来的。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不是立即返回而是永久等待。这种细节说明书和面试题很少讲透只有亲自打开源码才能真正沉淀成自己的知识。