包装类常量池是JVM自动启用的内存复用机制，主要减少对象分配和GC压力；仅Byte、Short、Integer、Character有默认缓存（-128～127或\u0000～\u007F），应优先用valueOf()或自动装箱，避免new和==比较。

包装类常量池本身不是用来“主动提速”的工具，而是一种 JVM 自动启用的内存复用机制。它对运行速度的提升是间接且有限的——主要体现在减少对象分配、降低 GC 压力上，而非让单次计算变快。真正能靠它获益的场景，是高频创建小范围数值包装对象且需频繁比较或存入集合时。

优先使用 valueOf() 而非构造器

直接调用 Integer.valueOf(100) 会命中缓存（-128～127），而 new Integer(100) 每次都新建对象，绕过常量池。后者不仅多一次堆分配，还增加 GC 负担。

• 推荐写法：Integer a = Integer.valueOf(120);
• 避免写法：Integer b = new Integer(120);
• 注意：自动装箱（如 Integer c = 120;）底层也调用 valueOf()，安全可用

控制数值范围，善用缓存区间

只有 Byte、Short、Integer、Character 有默认缓存，且范围固定：

• Integer/Byte/Short：-128 到 127（JVM 规范强制要求）
• Character：\u0000 到 \u007F（即 ASCII 0–127）
• Long、Float、Double 没有缓存，valueOf() 总是新建实例

若业务逻辑中大量使用如状态码、HTTP 状态（200、404）、枚举序号等集中于该区间的整数，天然适配缓存；若常用值超出范围（如用户 ID > 100000），则无法受益，不必强求。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

避免用 == 比较包装类，防止逻辑陷阱反拖性能

缓存带来的典型坑是误用 == 判断相等：

• Integer x = 100; Integer y = 100; x == y → true（缓存复用）
• Integer m = 200; Integer n = 200; m == n → false（堆上不同对象）

一旦在 if 或 switch 中依赖 ==，可能引发偶发性 bug，后续排查和修复成本远高于微秒级性能收益。统一用 .equals() 或解包为基本类型（int v = x;）更稳妥、可读、无歧义。

集合操作中注意缓存对查找效率的隐性影响

将 Integer 放入 HashSet 或作为 HashMap 的 key 时，若值落在缓存范围内，对象复用可略微减少哈希桶中的对象数量，但实际影响极小。真正关键的是：

• 确保 key 的 hashCode() 和 equals() 行为稳定（包装类已保证）
• 避免把非缓存范围的包装对象（如 new Integer(500)）反复插入再查找——虽不报错，但每次都是新对象，哈希冲突概率略升
• 高频场景下，直接用基本类型数组或 IntHashSet（如 Trove 或 Eclipse Collections）比依赖包装类缓存更有效

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南