不可变包装类天然防多线程污染，因其final类+final字段+无setter+构造即初始化，确保对象创建后值不可变；多线程读取无同步开销，“修改”实为新建对象。
直接用不可变包装类传递参数，是规避多线程污染最轻量、最可靠的方式——不是“能用”，而是“天然不需额外防护”。关键在于理解其不可变性如何切断数据竞争链路，而非仅把它当作普通类型用。
为什么包装类本身就能防污染
Java 中的 Integer、Long、Boolean、String 等包装类和字符串类，全部是 final 类 + 所有字段 final + 无 setter + 构造即完成初始化。这意味着：
- 一旦创建，对象内存地址里的值就再也不会被任何线程改写
- 多个线程同时读取同一个 Integer 实例（如
Integer.valueOf(100)返回的缓存对象），不会触发任何同步开销 - 看似“修改”操作（如
i++）实际是拆箱 → 计算 → 装箱 → 生成新对象，原对象毫发无损
业务参数中哪些该强制用不可变包装类
不是所有参数都适合裸用基本类型或可变容器。以下场景必须优先选用不可变类型：
-
配置标识类参数：如订单状态码、审批阶段 ID、租户 code —— 统一用
Integer或String，禁用int（虽基础类型也安全，但缺失 null 安全语义） -
时间戳与区间边界：用
Instant、LocalDateTime（Java 8+），不用Date或自定义含setTime()的时间容器 -
枚举型上下文：定义为
enum（本质不可变），避免用String或int模拟枚举并手动校验 -
透传凭证/Token 字符串：始终用
String，绝不转成char[]后在方法内反复修改（破坏不可变契约）
避开“伪不可变”陷阱的实操要点
常见误用会让不可变性失效，导致污染隐患重现：
-
别把包装类塞进可变容器后共享：例如将
Map<String, Integer>直接传给多个线程，而该 map 是new HashMap<>()—— 此时 map 本身可变，需转为Collections.unmodifiableMap()或用Map.of()（Java 9+） -
警惕防御性拷贝缺失：若参数含
List<String>，不要直接接收并暴露原始引用；构造时用List.copyOf(list)（Java 10+）或new ArrayList<>(list)，getter 中同样返回副本 -
禁止在日志或监控中意外修改：比如
log.info("req={}", req.getParams().toString())中，若toString()内部调用了可变字段的格式化逻辑并缓存了结果，可能引入竞态 —— 应确保toString()仅读取 final 字段
当业务需要“逻辑更新”时，怎么保持不可变契约
真实业务中常需“修改参数”，正确做法不是突破不可变，而是延续它：
- 设计参数类为
final，字段全final，提供withXxx(...)工厂方法返回新实例 - 例如：
OrderParam withStatus(Integer newStatus)内部return new OrderParam(this.id, newStatus, this.items) - 配合构建器模式（Builder）或记录类（
record，Java 14+）可大幅简化代码，且 record 默认满足不可变三要素
