动态代理中 equals、hashCode、toString 方法需要注意什么？

简化版

动态代理也会拦截 equals、hashCode、toString 这类 Object 方法，如果处理不当，可能导致集合去重异常、日志输出奇怪、代理对象比较语义混乱。通常要为这些方法设计明确策略：按代理身份比较、按目标对象比较，或按业务标识比较，不能随便透传。

详细版

在 JDK 动态代理中，接口方法调用会进入 InvocationHandler.invoke()，equals、hashCode、toString 也可能进入这个入口。CGLIB 代理也可能对这些方法产生影响。

常见风险包括：

toString() 触发远程调用或懒加载；
equals() 比较代理对象和目标对象时结果不符合预期；
hashCode() 不稳定导致对象放进 HashMap 后找不到；
代理对象作为缓存 Key 时语义混乱；
日志打印代理对象时暴露过多内部信息。

面试回答可以说：代理对象不只是业务方法要拦截，Object 基础方法也要考虑。尤其是 ORM 懒加载代理、RPC 代理、AOP 代理和缓存 Key 场景，equals/hashCode/toString 的策略必须稳定。

完整版教学

一、为什么 Object 方法在代理里也重要

很多人只关注代理业务方法，比如 createOrder()、pay()、query()，忽略了 equals、hashCode、toString。但 Java 对象在日志、集合、调试、缓存中经常隐式调用这些方法。

log.info("service={}", userService);
set.add(proxy);
map.get(proxy);
proxy.equals(other);

这些调用看起来不是业务调用，却会影响系统行为。如果代理没有正确处理，可能出现日志异常、集合查找失败、缓存 Key 不稳定等问题。

易错点：代理对象首先也是 Java 对象，Object 方法的语义不清，业务方法再正确也可能在集合和日志里翻车。

二、JDK 动态代理中 Object 方法怎么进入 InvocationHandler

JDK 动态代理会把代理对象的方法调用分发到 InvocationHandler.invoke()。业务接口方法会进来，equals、hashCode、toString 也需要处理。

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    if (method.getDeclaringClass() == Object.class) {
        return handleObjectMethod(proxy, method, args);
    }
    return method.invoke(target, args);
}

如果你无脑把所有方法都转发给目标对象，可能产生奇怪结果。例如 proxy.equals(proxy) 被转发成 target.equals(proxy)，如果目标对象的 equals 不认识代理，可能返回 false。一个对象和自己比较却不相等，这是非常危险的语义。

三、equals 的三种常见策略

代理对象的 equals 可以有不同策略。第一种是代理身份比较，即只有同一个代理实例才相等。第二种是目标对象比较，即两个代理背后的目标相等就相等。第三种是业务标识比较，比如按用户 ID、订单 ID。

策略	含义	适合场景
代理身份比较	`proxy == other`	AOP 代理、服务代理
目标对象比较	`target.equals(otherTarget)`	包装同一领域对象
业务标识比较	id 相同即相等	实体代理、懒加载代理

没有绝对标准，关键是稳定且符合使用场景。服务类代理一般不建议按业务字段比较，因为服务对象通常没有业务身份；实体懒加载代理则可能需要和真实实体按 ID 比较。

四、hashCode 必须和 equals 保持一致

hashCode 的规则是：如果两个对象 equals 为 true，它们的 hashCode 必须相同。代理里如果 equals 按目标对象比较，hashCode 却按代理实例地址返回，就会破坏 HashMap/HashSet。

错误示例:
  proxy1.equals(proxy2) == true
  proxy1.hashCode() != proxy2.hashCode()

结果:
  HashSet 可能同时保存两个“相等”对象
  HashMap 可能 put 后 get 不到

用数字例子理解：HashMap 有 16 个桶，proxy1.hashCode() 落到桶 3，proxy2.hashCode() 落到桶 11。即使 equals 返回 true，查找时先按 hash 定位桶，根本不会去桶 3 找。

因此设计代理对象相等性时，equals 和 hashCode 要一起设计，不能只处理其中一个。

五、toString 不应该触发重操作

toString() 经常被日志、调试器、异常消息隐式调用。如果代理的 toString() 触发远程调用、数据库懒加载或复杂序列化，就可能造成性能问题甚至递归调用。

log.info("user={}", userProxy); // 可能触发 userProxy.toString()

对于 RPC 代理，toString() 应该返回本地描述，比如接口名、服务名、版本、目标地址，而不应该真的调用远程服务。对于懒加载实体代理，toString() 是否触发加载要谨慎，很多 ORM 问题都和日志打印懒加载属性有关。

推荐 toString:
  UserServiceProxy{interface=UserService, version=1.0}

危险 toString:
  远程调用 getUserDetail()
  加载整个订单明细列表
  打印大型二进制字段

六、代理对象作为缓存 Key 的风险

如果把代理对象本身作为缓存 Key，必须确认 equals/hashCode 稳定。否则同一个业务对象可能因为代理实例不同而缓存不命中，或者不同代理因为目标 equals 相同而误命中。

Map<Object, Object> cache = new HashMap<>();
cache.put(proxy1, result);
cache.get(proxy2);

更稳的方式是用明确的业务 Key，而不是用代理对象：

String key = "user:" + userId;
cache.put(key, result);

在 Spring Cache、RPC、ORM 中，缓存 Key 都应该尽量基于稳定参数或业务标识。代理对象适合作为访问入口，不适合作为跨调用的身份标识。

七、工程中如何处理这些方法

实现 InvocationHandler 时，可以对 Object 方法单独分支。服务代理通常按代理身份处理 equals/hashCode，toString 返回代理描述。实体代理则需要结合实体 ID 和 ORM 规范。

private Object handleObjectMethod(Object proxy, Method method, Object[] args) {
    String name = method.getName();
    if ("toString".equals(name)) {
        return "Proxy(" + target.getClass().getName() + ")";
    }
    if ("hashCode".equals(name)) {
        return System.identityHashCode(proxy);
    }
    if ("equals".equals(name)) {
        return proxy == args[0];
    }
    throw new UnsupportedOperationException(name);
}

这段代码不是所有场景的标准答案，但体现了一个原则：Object 方法不要混进普通业务转发逻辑，要显式定义语义。

八、常见误区与追问

误区：动态代理只会拦截接口业务方法。 equals、hashCode、toString 这类基础方法也需要考虑。
误区：所有方法都直接转发给 target 最简单。 proxy.equals(proxy) 这类调用可能因此出现反直觉结果。
误区：toString 只是调试方法，怎么写都无所谓。 日志和调试器会频繁调用它，不能触发远程调用或重加载。
追问：equals 应该按代理还是目标比较？ 服务代理多按代理身份，实体代理可按业务 ID，关键是语义稳定。
追问：hashCode 为什么必须一起改？ HashMap/HashSet 先按 hash 定位，再用 equals 比较，二者不一致会破坏集合行为。
追问：代理对象能不能做缓存 Key？ 不推荐，优先使用稳定业务参数或业务 ID。
追问：RPC 代理的 toString 应该返回什么？ 返回接口、版本、服务地址等本地元信息，不应触发远程调用。

九、加强记忆

Object 方法在代理里记住“比较要稳定，hash 要一致，打印要轻量”。业务方法决定功能是否正确，equals/hashCode/toString 决定代理在集合、缓存和日志里是否可靠；手写动态代理时一定要单独处理这些基础方法。

简化版

详细版