java object类核心考察6个方法:tostring()、equals()、hashcode()、getclass()、clone()及wait/notify/notifyall;其中equals与hashcode必须同步重写,getclass不可重写,clone需实现cloneable接口,wait/notify须在synchronized块中调用。

Java面试中关于Object类的问题看似基础,实则常被用来快速判断候选人对面向对象本质和JVM底层逻辑的理解深度。答得泛泛而谈容易暴露知识断层,答得精准到位则能建立专业可信度。
先抓核心:Object类只有12个方法,但高频考察就6个
这6个是面试官真正会深挖的:toString()、equals()、hashCode()、getClass()、clone()、wait()/notify()/notifyAll()(三者常打包问)。其他如finalize()(已废弃)、registerNatives()(内部用)基本不考。
toString():别只说“打印用”,要讲清设计意图
- 默认返回
类名@十六进制哈希码(比如Person@1b6d3586),本质是getClass().getName() + "@" + Integer.toHexString(hashCode()) - 重写不是为了“好看”,而是为了调试可读性和日志可追溯性
- 面试时如果被问“为什么不用JSON序列化代替”,可回应:“
toString()是开发阶段的轻量级诊断工具,不依赖第三方库、无反射开销、不暴露敏感字段,适合快速定位问题”
equals() 和 hashCode():必须绑定回答,单讲一个就是扣分点
Java JDK 25 来自 OpenJDK 官方归档,版本为 JDK 25,本条下载地址已指向官方 Windows x64 zip 安装包直链,适合调试旧项目或兼容旧版 Java 运行环境。
-
equals()默认行为等价于==(引用比较),重写必须满足:自反性、对称性、传递性、一致性、非空性 -
hashCode()不是内存地址——JVM规范只规定“相等对象必须有相同哈希码”,具体算法由实现决定(HotSpot早期用地址,现在用带随机因子的混合计算) - 关键逻辑链要讲清楚:
- HashMap插入时:先算
hashCode()→ 定位桶位置 → 桶内遍历调用equals()比对 - 若只重写
equals()不重写hashCode()→ 相同内容对象可能落在不同桶 →get()永远查不到 - 若只重写
hashCode()不重写equals()→ 哈希碰撞增多,性能退化为链表遍历
- HashMap插入时:先算
getClass():强调它是运行时类型真相的唯一出口
-
final方法,不可重写,保证类型信息绝对可靠 - 与
instanceof的本质区别:instanceof可能返回true(如ArrayListinstanceofList),但getClass()返回的是精确的、擦除泛型后的实际类(ArrayList.class) - 实际用途举例:做严格类型校验(如序列化框架拒绝非目标类实例)、动态代理中获取原始类型
clone():浅拷贝陷阱是必考点
- 必须实现
Cloneable接口(否则抛CloneNotSupportedException),且需将protected clone()改为public - 默认是浅拷贝:基本类型值复制,引用类型只复制地址 —— 修改副本中的对象属性,原对象也会变
- 深拷贝方案要能说出两种:
- 手动递归克隆(适合结构简单)
- 序列化+反序列化(通用但有性能和Serializable约束)
wait/notify 系列:聚焦“为什么必须在 synchronized 块里调用”
- 根本原因:这些方法操作的是对象的监视器锁(monitor),而 monitor 只有在持有锁时才可操作
-
wait()会释放锁并挂起线程;notify()不释放锁,只是唤醒等待队列中的一个线程 - 常见错误:在
if中调用wait()(应为while循环),防止虚假唤醒 - 补充一句:“
LockSupport.park()是更底层的线程阻塞机制,wait/notify是基于 monitor 的高级封装”
基本上就这些。真正拉开差距的,不是背出方法名,而是能说清每个方法存在的理由、不这么设计会出什么问题、以及它在JVM或集合框架中真实参与的执行链条。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










