Integer用==比较有时对、有时错，因其在-128至127范围内复用缓存对象，超出则新建实例，==比较的是引用而非值；Boolean、Byte、Character（0–127）、Short、Long也有类似缓存，但Float和Double无缓存；应统一用equals()或基本类型避免NPE风险。
为什么 Integer 用 == 比较有时对、有时错
因为 Integer 在 -128 到 127 范围内会复用缓存对象，超出范围则每次新建实例。所以 == 实际比较的是引用是否相同，不是值是否相等。
常见错误现象：Integer a = 100; Integer b = 100; System.out.println(a == b); // true，但换成 200 就输出 false。
- 这是 JVM 规范要求的行为，由
Integer.valueOf(int)实现，不是 bug - 编译期字面量（如
Integer c = 100;）也走valueOf，所以同样受缓存影响 - 手动调用
new Integer(100)绕过缓存，但已废弃，且必然导致==为false
Integer.valueOf() 的缓存范围能改吗
能，但不建议。JVM 启动参数 -Djava.lang.Integer.IntegerCache.high=256 可扩大上限，但只影响当前 JVM 实例，且必须在类加载前设置。
使用场景极少：比如遗留系统里大量 == 比较且无法改代码，又恰好集中在某个略超 127 的固定值上。
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 下限 -128 固定不可调
- 修改后不会影响已加载的
Integer类，需确保Integer尚未被初始化（通常意味着得在 main 前设置） - 多数框架（Spring、Hibernate）或容器（Tomcat）会提前触发
Integer加载，此时参数无效
哪些包装类也有类似缓存
只有 Boolean、Byte、Character（\u0000–\u007f）、Short、Integer 和 Long 的 valueOf 方法有缓存，但范围各不相同。
性能影响很小，但语义风险一致：依赖 == 比较包装类，就等于依赖缓存策略。
-
Boolean缓存true和false两个实例（总是安全） -
Character只缓存 0–127（即 ASCII 可见字符），不是 -128–127 -
Short和Long缓存范围也是 -128 到 127，不可配置 -
Float和Double没有缓存，valueOf每次返回新对象
实际编码中怎么避免踩坑
统一用 .equals() 比较包装类值，或者优先用基本类型 int。
容易被忽略的点：自动拆箱可能抛 NullPointerException，尤其当变量可能为 null 时。
-
if (a != null && a.equals(b))比a == b更安全，也比a.intValue() == b.intValue()更健壮 - 数据库映射字段（如 MyBatis 返回
Integer）常为null，直接==或拆箱极易 NPE - Lombok 的
@Data生成的equals()默认对包装类用Objects.equals(a, b)，已处理null安全
