Object类性能瓶颈源于重写toString、equals、hashCode、clone等方法不当；应避免字符串拼接、确保equals与hashCode成对轻量实现、慎用clone、减少反射及getClass高频调用。
Object 类本身不直接涉及性能瓶颈，但它的几个核心方法（toString、equals、hashCode、clone）在高频调用场景下，若实现不当，会显著拖慢程序。优化重点不在“改 Object”，而在于**重写这些方法时遵循高效、安全、可预测的原则**。
重写 toString 时避免字符串拼接开销
默认 toString 返回 类名@哈希值，虽快但无业务意义；若重写后频繁调用（如日志、调试、集合打印），低效拼接会放大成本。
- 不用
+拼接多个字段，尤其在循环或高并发日志中——每次+都隐式新建 StringBuilder - 优先用
String.format或StringBuilder.append()手动构建，控制对象创建次数 - 敏感字段（如密码、token）绝不出现在 toString 中，避免无意泄露和额外字符串处理
- 若对象字段较多且 toString 调用极频繁（如监控指标打点），可考虑缓存结果（加 volatile 字段 + 双检锁），但需权衡内存与一致性
equals 和 hashCode 必须成对重写且计算轻量
这两个方法常被 HashMap、HashSet、ConcurrentHashMap 等集合高频调用。低效实现会导致哈希桶分布不均、链表过长，甚至退化为线性查找。
- hashCode 应基于少量稳定字段计算，避免调用 getter（可能含逻辑）、避免调用其他对象的 hashCode（易引发连锁调用）
- 推荐用
Objects.hash(f1, f2, f3)，它内部是位运算+素数乘法，比手写f1 * 31 + f2 * 31 * 31更简洁且足够快 - equals 中先做引用相等（
this == obj）和类型检查（obj instanceof Xxx），再逐字段比较；布尔/数字字段优先比，字符串用Objects.equals(a, b)防 NPE - 禁止在 equals 中调用耗时操作（如数据库查询、远程调用），它必须是纯内存判断
慎用 clone，优先考虑构造器或静态工厂
Object.clone() 是浅拷贝，且要求类实现 Cloneable 接口；重写时若做深拷贝，容易触发大量对象创建和递归调用，GC 压力陡增。
立即学习“Java免费学习笔记（深入）”；
- 多数场景下，用构造器复制（
new Person(p.name, p.age)）或静态工厂（Person.copyOf(p)）更清晰、可控、易测试 - 若必须 clone，避免在循环里调用；对含集合字段的对象，不要用
list.clone()（仍是浅拷贝），改用new ArrayList(originalList) - 不可变对象（如 String、LocalDateTime）无需 clone，直接复用即可
避免在高频路径中反射调用 getClass 或 notify 等方法
getClass() 本身很快（final 方法，JIT 可内联），但若配合反射（如 clazz.getDeclaredMethod(...)）则开销巨大；wait/notify 属于线程同步原语，误用会阻塞、死锁，间接影响吞吐。
- 类型判断优先用
instanceof，比obj.getClass() == Xxx.class更安全、更高效 - 不要为省几行代码，在 for 循环里反复调用
obj.getClass().getSimpleName()—— 提前提取并复用 - wait/notify 应仅用于线程协作场景（如生产者-消费者），禁止用于“延迟执行”或“模拟 sleep”，这类需求用 ScheduledExecutorService
