Java中HashMap可通过自定义不可变key类实现复合主键，需正确重写equals()和hashCode()；字符串拼接或Map.Entry等方式不推荐用于生产环境；多线程场景应使用ConcurrentHashMap并注意缓存生命周期管理。
Java 中 HashMap 本身不支持“复合主键”这个概念，但你可以通过设计一个**能准确表达多个字段组合唯一性**的 key 对象，来实现逻辑上的复合主键缓存。关键不在 HashMap，而在 key 的设计是否满足 equals() 和 hashCode() 契约。
用自定义对象做复合 key
这是最常用、最清晰的方式。比如订单系统中，用 (userId, orderId) 作为联合标识：
- 定义一个不可变类，如
OrderKey，包含userId和orderId字段（建议用final） - 重写
hashCode()：必须基于所有参与复合的字段计算，推荐用Objects.hash(userId, orderId) - 重写
equals()：严格比较每个字段，且要处理 null、类型检查、自反性等（参考标准四步模板） - 构造后不要修改字段——否则 hash 桶位置错乱，
get()就失效了
用字符串拼接做 key（仅限简单场景）
例如：userId + ":" + orderId。优点是快、无额外类；缺点明显：
- 如果字段本身含冒号或特殊字符，会破坏唯一性（如
"123:abc"和"12:3abc"拼出来一样） - 没有类型安全，运行时才暴露问题
- 可读性和调试成本高，不适合复杂业务
- 不推荐用于生产环境，仅适合原型或日志临时缓存
用 Map.Entry 或 Pair 类型？不推荐
像 new AbstractMap.SimpleEntry(userId, orderId) 或 Guava 的 Pair，看似省事，但有隐患：
立即学习“Java免费学习笔记（深入）”；
- 它们的
hashCode()和equals()实现虽可用，但语义模糊——不是为业务主键设计的 - 缺乏命名，别人看不懂这个 pair 到底代表什么（是订单？还是库存批次？）
- 无法封装校验逻辑（比如 orderId 不能为空），违反封装原则
- 一旦需求扩展（比如加 tenantId），改起来比自定义类更痛苦
线程安全与缓存生命周期要同步考虑
复合 key 只解决“怎么存”，但缓存是否可靠，还取决于使用方式：
- 多线程读写必须换
ConcurrentHashMap，不能靠 synchronized 包一层 compute 方法（性能差、易出错） - 如果 key 中字段可能变更（比如用户迁移到新租户），要确保旧 key 能被清理，或设计成不可变+新 key 替换
- 缓存大对象 Value 时，注意扩容开销；可预估容量初始化：
new ConcurrentHashMap(expectedSize / 0.75 + 1) - 避免内存泄漏：key 或 value 引用外部长生命周期对象（如 ServletContext、静态集合）
