Java包装类设计为不可变，是为了保障线程安全、支持缓存优化、契合值语义、确保hashCode/equals稳定性；其内部字段为final，构造后状态固定，避免竞态、污染和集合失效等问题。
Java 包装类（如 Integer、Boolean、Double 等）是不可变的，这是设计上的主动选择，不是技术限制。回答这类面试题，核心是讲清“为什么不可变”，而不是只说“它就是不可变的”。
不可变性保障线程安全
包装类被广泛用于多线程场景（比如缓存、集合、并发计算），如果允许修改内部值（比如让一个 Integer 对象从 10 变成 20），就会引发竞态问题。不可变性天然避免了同步开销——对象一旦创建，状态就固定，多个线程读取时无需加锁或 volatile 修饰。
- 对比可变类（如自定义的
MutableInt）：必须手动同步，否则可能读到中间状态 -
Integer.valueOf(42)返回的对象，其value字段是final int，构造后无法更改
支持缓存与享元优化
小范围整数（-128 到 127）等常用值会被缓存（通过 IntegerCache），多次调用 Integer.valueOf(100) 返回的是同一个对象引用。如果包装类可变，缓存对象被某处修改，会“污染”所有使用该缓存的地方，导致逻辑错乱。
- 例如：
Integer a = Integer.valueOf(100); Integer b = Integer.valueOf(100);→a == b为 true - 若
a可被修改，b的值也会意外改变，破坏语义一致性
契合值语义与函数式编程思想
包装类代表的是“数值本身”，不是“某个容器”。Java 希望开发者把 Integer 当作和 int 一样看待——操作它应产生新对象，而非修改旧对象。这与字符串（String）不可变的设计哲学一致，也便于配合 Stream、Optional 等函数式 API 使用。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
Integer i = 5; i += 3;实际执行的是i = new Integer(i.intValue() + 3) - 自动拆箱/装箱过程隐含对象创建，不可变性让这种转换更安全、更可预测
避免 equals/hashCode 不一致风险
不可变对象能确保 hashCode() 和 equals(Object) 的结果在生命周期内恒定。如果包装类可变，对象加入 HashSet 后修改值，会导致哈希码变化，再也找不到它（违反集合契约）。
- 比如：
Set<integer> set = new HashSet(); set.add(100);</integer>→ 若 100 对象后来变成 200，set.contains(100)可能返回 false - 而实际中不会发生，正因为
Integer的不可变保证了哈希稳定性
不复杂但容易忽略：不可变 ≠ 不能重新赋值变量，而是对象状态不可改。重点不是背结论，而是能结合线程安全、缓存机制、值语义、集合契约这四个维度，讲清楚“为什么这样设计更合理”。
