Integer.valueOf() 在 -128 至 127 范围内返回缓存对象，超出范围则新建实例，这是 JVM 规范要求；String.intern() 在 JDK 7+ 后将字符串加入堆中常量池，仅当内容相同时复用；字面量直接入池，new String() 在堆新建对象并共享池中内容；自定义类无常量池，需手动缓存并注意生命周期管理。
Integer.valueOf() 为什么有时返回缓存对象，有时不是？
因为 Integer 在 -128 到 127 范围内会复用缓存对象，超出范围就新建实例。这不是 bug，是 JVM 规范明确要求的行为（其他如 Byte、Short、Character 也有类似缓存，但范围固定；Long 和 Float 没有）。
常见错误现象：Integer a = 128; Integer b = 128; System.out.println(a == b); // false —— 用 == 比较包装类值，结果出人意料。
- 使用场景：做数值计算或传参时，只要用
.equals()或直接解包（int c = a;），缓存与否不影响逻辑 - 参数差异：构造器
new Integer(128)总是新建对象，而Integer.valueOf(128)在范围外也新建，但范围内的调用才命中缓存 - 性能影响：缓存减少对象分配，但别指望靠它优化高频数值操作——JIT 编译后差别极小
- 容易踩的坑：在集合里存
Integer后用==查找，或者在switch中误以为所有Integer都能当 case 值（实际只支持编译期常量）
String.intern() 是不是总能把字符串塞进常量池？
不是。intern() 的行为取决于 JDK 版本和字符串是否已存在池中：JDK 7+ 后，常量池移到堆内存，intern() 会检查池中是否有内容相同的字符串，有则返回其引用，没有则把当前字符串对象加入池并返回它。
常见错误现象：String s1 = new String("hello"); String s2 = s1.intern(); System.out.println(s1 == s2); // false —— 因为 s1 是堆上新对象，s2 是池中引用，两者地址不同。
立即学习“Java免费学习笔记（深入）”；
- 使用场景：大量重复字符串（如解析日志中的状态码、枚举名）且需频繁比较时，可考虑
intern()降低内存占用和equals()开销 - 性能影响：首次调用
intern()有哈希查找开销；高并发下可能成为瓶颈（内部用字符串表加锁） - 容易踩的坑：对动态拼接字符串（如
"a" + i）反复调用intern()，不仅没收益，还可能导致常量池膨胀甚至 OOM；另外，G1 GC 下未配置-XX:StringTableSize可能引发哈希冲突加剧
String 字面量和 new String() 创建的对象在常量池里怎么共存？
字面量（如 "abc"）在类加载时就进入常量池；而 new String("abc") 会在堆上创建新对象，其内容字段指向常量池里的 "abc" —— 这是两个独立对象，只是内容共享。
常见错误现象：String s1 = "abc"; String s2 = new String("abc"); System.out.println(s1 == s2); // false —— 明明内容一样，== 却不成立。
- 使用场景：绝大多数情况应优先用字面量，除非明确需要隔离可变性（比如传给一个可能修改内部
char[]的旧 API） - 参数差异：JDK 9+ 的
String内部用byte[]存储，但常量池仍按内容判等，不影响上述机制 - 兼容性影响：某些安全框架（如早期 Spring EL）依赖
==判断字符串是否为“可信字面量”，此时混用new String()可能绕过校验
为什么自定义类没有类似 String 的常量池机制？
因为常量池是 JVM 层面对特定类型（String、基本类型包装类、Class 对象）做的硬编码优化，不是语言特性，也不开放给用户代码直接复用。
常见错误现象：试图模仿 String.intern() 给自己的 User 类写个 cache() 方法，并期望 JVM 自动识别、去重、GC 友好——结果发现得自己管生命周期，还容易内存泄漏。
- 替代方案：用
ConcurrentHashMap手动缓存典型实例（如枚举语义的不可变对象），配合弱引用或软引用来缓解 GC 压力 - 容易踩的坑：缓存 key 用了可变字段（如
user.setName("x")后再查缓存），导致哈希错位；或忘了重写hashCode()和equals()，使缓存失效 - 复杂点在于：JVM 的字符串常量池能随类卸载自动清理，而你手写的缓存必须显式管理，尤其在模块热部署、OSGi 等场景下，残留引用极易引发 ClassLoader 泄漏
