java框架动态代理依赖object类的hashcode、equals、tostring和getclass方法：前者保障缓存与判重正确性，tostring支撑可观测性，getclass影响类型识别，wait/notify因绑定对象头而无法代理。
Java 框架底层的动态代理本身不直接靠重写 Object 方法来增强业务逻辑，但它的运行和扩展高度依赖 Object 类中几个关键方法的语义与行为——尤其是 hashCode、equals、toString 和 getClass。这些方法不是“被增强的目标”，而是支撑代理机制稳定、可识别、可观测的基础设施。
代理对象必须正确实现 hashCode 与 equals
框架（如 Spring AOP）生成的代理对象常作为 Map 的 key 或集合元素使用。若代理对象未正确转发 hashCode 和 equals 到目标对象，就会导致：
- Spring 单例 Bean 缓存失效（BeanDefinition 判重出错）
- MyBatis 一级缓存无法命中（MappedStatement 的 key 比较失败）
- 自定义注解处理器或条件判断（如
@ConditionalOnBean）误判类型存在性
JDK 动态代理默认会将 hashCode、equals、toString 这三个 Object 方法的调用自动委托给目标对象（只要目标对象已正确重写）。这是由 Proxy 类内部约定保障的，无需手动处理；但 CGLIB 代理需显式确保子类重写时调用 super.xxx() 或委托给目标实例。
toString 是日志与调试的关键入口
几乎所有主流框架在打印参数、记录异常、暴露健康端点时，都会调用入参或返回值对象的 toString()。代理对象若返回默认 ClassName@hash，就失去业务意义。
- Spring MVC
@RequestBody绑定失败时，错误日志会输出 DTO 的toString() - Feign 客户端开启 full 日志后，请求体以
toString()形式展示 - IDE 调试器变量视图、Actuator 的
/actuator/health等都依赖它
因此，真实对象应重写 toString（推荐用 Lombok @ToString），而代理对象会自动继承该行为 —— 前提是目标类已提供有意义的实现。
getClass 决定类型安全与 instanceof 行为
代理对象的 getClass() 返回的是动态生成的代理类（如 $Proxy123 或 UserServiceImpl$$EnhancerByCGLIB$$abc），这会导致直接使用 instanceof 或强制转型失败。
- Spring AOP 通过
AopProxyUtils.ultimateTargetClass()向上追溯原始类 - 框架内部普遍用
Advised.getOriginalTargetClass()获取真实类型 - 业务代码中应避免对代理对象做
obj.getClass() == UserServiceImpl.class判断
真正可靠的类型判断方式是：面向接口编程 + Advised 接口检查，或使用 Spring 的 AopUtils.isAopProxy() 和 AopUtils.getTargetClass() 工具方法。
wait/notify 不参与业务增强，但影响同步语义
wait、notify、notifyAll 属于 JVM 监视器（monitor）原语，它们绑定在对象头（object header）上，无法被代理拦截或重定向。
- 对代理对象调用
wait()，实际阻塞的是代理实例自身，而非目标对象 - 这意味着：不能用代理对象做线程协作的同步点（如生产者-消费者模型中的共享锁）
- 若业务逻辑依赖
synchronized(obj)+wait/notify，应确保锁对象是原始目标实例，而非其代理
这也是为什么框架中涉及并发控制的模块（如 ThreadPoolExecutor、Dubbo RPC 同步等待）通常绕过代理，直接操作目标对象或使用独立同步结构。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
