integer在-128到127范围内用==比较返回true，因valueof复用integercache中同一对象；范围外则每次新建对象，==比较地址必为false；应统一使用equals()或intvalue()比较值。
不能用高并发流配合缓存机制来透彻理解包装类比较中的红线边界。
高并发流不参与包装类缓存逻辑
Integer、Boolean 等包装类的缓存行为（如 IntegerCache 的 -128~127 范围）由 JVM 在类加载和 valueOf() 调用时静态决定，与线程数量、流式处理方式、CompletableFuture 封装或 Flux 并行度完全无关。无论你用单线程逐行读，还是用 1000 个线程并发调用 Integer.valueOf(128)，结果始终是：每次返回新对象，== 恒为 false。
“动态比对”无法暴露缓存边界
所谓“在高并发流中比对数据指纹”或“运行时反复创建再比较”，本质是事后校验。而包装类缓存是否生效，只取决于对象创建路径是否走 valueOf()，以及数值是否落在缓存区间内。并发本身不会放大、也不会掩盖这个边界——它只是把本就确定的行为并行执行了多次。你看到的“有时 == 为 true，有时为 false”，从来不是并发导致的，而是输入值是否为 127 或 128 的必然结果。
真正有效的验证方式很简单
- 用 BufferedReader 逐行读取文本数字（如 "127"、"128"），再调用 Integer.valueOf(Integer.parseInt(line)) —— 这能绕过编译期优化，真实触发缓存判断
- 把生成的对象存入 ArrayList，再用 == 和 equals() 分别比对相同数值的两次结果
- 观察到：127 对应的两个对象 == 为 true；128 对应的两个对象 == 为 false；所有情况 equals() 都为 true
混淆技术层级会掩盖本质
把“高并发”“流式封装”“指纹比对”套在包装类问题上，容易让人误以为缓存行为是动态、可配置、受并发影响的。实际上，它是一套静态、确定、JVM 级别的对象复用策略。想透彻理解红线边界，关键在于看清：缓存只发生在创建环节，只影响引用相等性，从不改变数值语义。其他任何包装，都是干扰项。
