写 Java 的人应该都见过这两个方法：Integer.parseInt("100")和Integer.valueOf("100")都能把一个字符串变成整数。看起来一模一样对吧？我第一次用的时候也以为它们只是同一个功能的两种写法，直到有一次处理大批量字符串转换、顺手点进源码看了一眼，才意识到这里面的门道比想象中多得多。返回值类型、空值处理、缓存机制、自动装箱联动，甚至 JVM 参数都能掺一脚进来。
这篇文章不打算只罗列结论，我会直接把 JDK 源码拎出来逐行拆，把IntegerCache缓存机制的每个角落都翻一遍，再用实际例子带你看看什么场景该用哪个。无论你是刚入门还是已经工作了几年，我相信都能从中找到以前忽略的细节。
1. 先看最直观的差异：返回类型与使用习惯
1.1 返回类型不同，根本定位不同
Integer.parseInt(String s)返回的是基本类型int，而Integer.valueOf(String s)返回的是包装类型Integer。一个是拆完箱的原始值，一个是带对象的引用，这就是两者最底层的区别。
写代码时这俩经常混用，是因为 Java 的自动装箱和拆箱机制太方便了。你写Integer n = Integer.parseInt("100");，编译器会偷偷帮你调用Integer.valueOf(100)完成装箱；反过来你写int i = Integer.valueOf("100");，编译器又会自动拆箱成int。正是因为这些自动转换，很多人在日常开发中根本感觉不到差异。
但在方法签名、泛型、反射这些场景下，类型差异就会凸显出来。比如List<Integer>里只能放Integer，你要想把字符串转换后直接塞进去，用parseInt还需要手动装箱一次，用valueOf就直接省了一步。
1.2 空值和异常处理：一个毫不留情，一个也会炸
Integer.parseInt(null)会直接抛NumberFormatException，因为字符串是null时无法解析。Integer.valueOf(null)也一样会抛异常，并不会因为返回对象就多一层空值保护。
不过有一个点很多人没注意：如果传入的是空字符串""，两个方法都会抛NumberFormatException。实际项目里经常有人以为valueOf返回包装类型就能容忍空值，这是误区。想要优雅处理，只能自己先做空判断，或者用try-catch包一层。
注意：
parseInt和valueOf在传入非法字符串时抛出的都是NumberFormatException，两者的异常行为可以说完全一致，别指望靠换方法解决解析失败问题。
2. 源码级逐行剖析：JDK 里到底做了什么
2.1 parseInt 的源码逻辑：一路循环算到底
点开java.lang.Integer源码，parseInt的真正实现在parseInt(String s, int radix)里，radix是进制数，默认调用时传入 10。
我挑核心逻辑说。它会先检查字符串是否为空、进制是否在Character.MIN_RADIX=2到Character.MAX_RADIX=36之间，然后从字符串第一个字符开始判断正负号，接着循环遍历每个字符，把字符转换成对应的数字值，不断累加到result上：
public static int parseInt(String s, int radix) throws NumberFormatException { if (s == null) { throw new NumberFormatException("null"); } if (radix < Character.MIN_RADIX) { throw new NumberFormatException("radix " + radix + " less than Character.MIN_RADIX"); } if (radix > Character.MAX_RADIX) { throw new NumberFormatException("radix " + radix + " greater than Character.MAX_RADIX"); } int result = 0; boolean negative = false; int i = 0, len = s.length(); int limit = -Integer.MAX_VALUE; if (len > 0) { char firstChar = s.charAt(0); if (firstChar < '0') { if (firstChar == '-') { negative = true; limit = Integer.MIN_VALUE; } else if (firstChar != '+') { throw NumberFormatException.forInputString(s); } if (len == 1) { throw NumberFormatException.forInputString(s); } i++; } int multmin = limit / radix; while (i < len) { int digit = Character.digit(s.charAt(i++), radix); if (digit < 0 || result < multmin) { throw NumberFormatException.forInputString(s); } result *= radix; if (result < limit + digit) { throw NumberFormatException.forInputString(s); } result -= digit; } } else { throw NumberFormatException.forInputString(s); } return negative ? result : -result; }注意源码里用的是负数累加，最后再转回正数，这是为了处理Integer.MIN_VALUE的边界情况。如果直接用正数累加，-2147483648的绝对值会溢出。这段代码充分考虑了边界溢出问题，这也是parseInt的一个隐藏能力：它能把"-2147483648"正确解析出来，而不是报溢出异常。
parseInt的最终归宿就是返回一个基础类型int，整个链路完全没有涉及到任何缓存或者对象创建。它做的事情就是纯计算，算完交付。
2.2 valueOf 的源码逻辑：parseInt 之后还有一道缓存工序
Integer.valueOf(String s)的实现有意思了。它先调用parseInt拿到int值，然后调用重载方法valueOf(int i)：
public static Integer valueOf(String s, int radix) throws NumberFormatException { return Integer.valueOf(parseInt(s, radix)); } public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) { return IntegerCache.cache[i + (-IntegerCache.low)]; } return new Integer(i); }所以完整的链路是：字符串 →parseInt解析成int→ 进入valueOf(int)→ 检查是否在缓存范围内 → 命中就返回缓存对象，没命中就new Integer。
这段代码也解释了为什么valueOf会比parseInt多一点点开销：不管怎样都要多一次方法调用，多一次范围比较。但这点开销通常小到可以忽略，只有在千万级循环里才能看出差异。
IntegerCache.low和IntegerCache.high就是缓存机制的边界值。下一节我会专门拆开讲，这是全文的重头戏。
3. 核心隐藏机制：IntegerCache 缓存深度解构
3.1 缓存范围到底是怎么定的
IntegerCache是Integer里的一个私有静态内部类。直接看源码：
private static class IntegerCache { static final int low = -128; static final int high; static final Integer cache[]; static { int h = 127; String integerCacheHighPropValue = VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); if (integerCacheHighPropValue != null) { try { int i = parseInt(integerCacheHighPropValue); i = Math.max(i, 127); h = Math.min(i, Integer.MAX_VALUE - (-low) -1); } catch (NumberFormatException nfe) { // 配置无法解析时忽略，使用默认值 } } high = h; cache = new Integer[(high - low) + 1]; int j = low; for (int k = 0; k < cache.length; k++) { cache[k] = new Integer(j++); } assert IntegerCache.high >= 127; } private IntegerCache() {} }默认情况下low固定是-128，high固定是127，缓存数组大小就是127 - (-128) + 1 = 256，刚好涵盖 256 个Integer对象。这些对象在类加载阶段就全部创建好了，常驻内存。
有人会问：为什么下界是 -128 而不是 -256？这其实是 JLS（Java 语言规范）的要求，规范规定Integer缓存的下界必须至少是 -128，上界必须至少是 127。这是为了确保一些基础语义在所有 JVM 实现上保持一致。HotSpot 实现直接把下限定死为 -128，上限默认为 127，但上限可通过 JVM 参数调大。
3.2 valueOf 之外，自动装箱也在偷偷用缓存
值得强调的是，IntegerCache不只是服务Integer.valueOf(int)，编译器生成的自动装箱代码也会调用valueOf(int)。看这段代码：
Integer a = 100; Integer b = 100; System.out.println(a == b); // 输出 truea和b的赋值本质上是Integer.valueOf(100)，100 落在缓存区间内，所以两个变量指向同一个对象。==比较的是引用地址，自然为true。
再看：
Integer c = 200; Integer d = 200; System.out.println(c == d); // 输出 false200 超过了缓存上界 127，valueOf返回的是两个不同的new Integer(200)对象，==结果为false。
这就是网上流传很广的“Java 整数缓存面试题”的底层原理。很多人背结论说“-128 到 127 之间用 == 相等”，但不知道真正驱动这个行为的是IntegerCache和valueOf的联动。
我还想提醒一个常见的理解偏差：不要用new Integer(100)然后去和Integer.valueOf(100)比较。因为new关键字是实打实创建新对象，完全不经过缓存，即使值在缓存范围内，引用也是不同的：
Integer e = new Integer(100); Integer f = Integer.valueOf(100); System.out.println(e == f); // 输出 false这个坑在旧代码里很常见。不过 JDK 9 开始Integer的构造器已经被标记为废弃，官方明确推荐使用valueOf，所以新项目里基本不会再踩。
3.3 修改缓存上限的骚操作：AutoBoxCacheMax
IntegerCache源码里有一段从系统属性读取配置的逻辑，VM.getSavedProperty("java.lang.Integer.IntegerCache.high")会读取 JVM 启动时保存的参数。对应到 HotSpot VM 上，常用的设置方式是：
java -XX:AutoBoxCacheMax=1000 MyApplication或者通过系统属性：
java -Djava.lang.Integer.IntegerCache.high=1000 MyApplication执行之后，缓存上界就从 127 变成 1000。此时：
Integer c = 200; Integer d = 200; System.out.println(c == d); // 输出 true，因为缓存范围被改大了这个参数在某些框架中很有用。比如用反射大量操作包装类型的时候，扩大缓存范围可以减少重复对象创建；或者在做某些性能敏感计算、需要大量Integer对象复用时，也能降低 GC 压力。
但我不建议随意调大这个参数。缓存数组是类加载时一次性创建的，范围越大，内存占用越高。如果一个应用把上限调到 100000，那就要一次性创建十万个Integer对象常驻内存。对于对象复用需求不明确的应用来说，这是白白浪费内存。
注意：
-XX:AutoBoxCacheMax是 HotSpot VM 特有的参数，其他 JVM 实现不一定支持。另外就算调大了缓存上限，也千万别在业务代码里依赖==来判断两个Integer是否相等，因为代码一旦换到默认参数的 JVM 上就会静默出错。
还有个小细节：源码里对配置值做了Math.max(i, 127)，意思是如果你配置的值比 127 还小，会被强制拉回 127，保证至少满足 JLS 规范。这就是你没法通过配置把缓存上界降到 100 的原因。
4. 实际项目中的选型与性能：到底该用哪个
4.1 性能对比：差的那点时间值得在意吗
我拿一段简单的循环做过测试，连续执行一百万次字符串转整数：
long start1 = System.nanoTime(); for (int i = 0; i < 1000000; i++) { int n = Integer.parseInt("12345"); } long end1 = System.nanoTime(); long start2 = System.nanoTime(); for (int i = 0; i < 1000000; i++) { Integer n = Integer.valueOf("12345"); } long end2 = System.nanoTime();实测下来valueOf普遍比parseInt慢 5%~10% 左右。因为valueOf(String)内部走了一遍parseInt，又走了一次valueOf(int)，多了一次方法调用和缓存范围比较。这个差距在大批量数值转换时能看出来，但绝大部分业务系统根本达不到这种量级。
如果说得更直白一点：一百万个 String 转 Integer，两者的耗时差异通常在几十毫秒以内。如果你的应用性能瓶颈在这里，那应该先想想是不是整体架构出了什么问题，而不是纠结选哪个方法。
不过在真正的高性能场景，比如网关解析海量报文、大数据清洗管道里反复做字符串转数字，我会优先选择parseInt，然后把结果直接赋给基本类型变量，避免任何装箱开销。
4.2 判等陷阱：== 与 equals 的抉择
这节是重点，因为选型不只影响转换，还影响后续的比较逻辑。
用parseInt拿到int，用==比较是值比较，怎么比都不会错。但用valueOf拿到Integer，再用==比较就得特别小心：
int m = 300; int n = 300; System.out.println(m == n); // true，基础类型直接比值 Integer p = Integer.valueOf("300"); Integer q = Integer.valueOf("300"); System.out.println(p == q); // false，超出缓存范围，比的是引用地址 int r = 300; Integer s = Integer.valueOf("300"); System.out.println(r == s); // true，Integer 会自动拆箱成 int 再比较第三种情况是最容易迷惑人的：Integer和int用==比较时，JVM 会把Integer自动拆箱成int，所以结果是true。但两个Integer之间用==就不一定了。
我的建议很简单：包装类型之间一律用equals比较，不要用==。就算你知道缓存范围，也难保别人不会改 JVM 参数、不会换 JDK 版本、不会把代码移植到其他 JVM 实现。在看不到的地方依赖隐式行为，等于给自己埋雷。
4.3 最佳实践：什么场景选谁
整理一下我平时的选型习惯，供你参考：
- 需要
int基本类型：比如参与数值计算、作为数组下标、作为方法入参且方法签名是int，直接用parseInt，语义最清晰。 - 需要
Integer对象：比如存入List<Integer>、Map的 value、泛型容器中，用valueOf，避免额外的手动装箱。 - 需要把结果可能为 null 的情况后续处理：两个都不支持 null 字符串，所以别指望哪个更“宽容”，做好前置判空才是正事。
- 需要手动指定进制：比如解析二进制字符串
Integer.parseInt("1010", 2)，两个方法对应的重载都支持。 - 高频批量转换：用
parseInt并配合基本类型数组或集合，减少对象创建。
如果拿不准，可以记住一个原则：代码希望拿到基本类型就选parseInt，希望拿到包装类型就选valueOf。让类型自己决定，而不是靠自动装箱和拆箱帮你兜底，代码的可读性和可维护性会好很多。
5. 常见问题与避坑实录
5.1 经典面试题复盘
几乎每次面试我都会问到或被人问到整数缓存相关的问题，整理几个最典型的：
Integer a = 100; Integer b = 100; a == b结果是什么？答案是true，因为自动装箱调用valueOf(100)，命中缓存。Integer c = 200; Integer d = 200; c == d结果是什么？答案是false，超出缓存范围，各 new 各的。Integer e = new Integer(100); Integer f = 100; e == f结果是什么？答案是false，new不经过缓存。Integer g = Integer.valueOf("127"); Integer h = 127; g == h结果是什么？答案是true，值在缓存范围，同一个对象。Integer i = Integer.valueOf("128"); int j = 128; i == j结果是什么？答案是true，混用时会自动拆箱。
最后一类混用最容易答题出错。Integer和int比较时，Integer会先拆箱成int，所以本质是int == int，永远比值。
5.2 容易被忽略的细节清单
第一，valueOf(String)在 JDK 各版本里的实现路径基本一致，都是先parseInt再走valueOf(int)，但不同版本源码写法略有差异。比如 JDK 9 后移除了Integer的公开构造器，缓存内部对象的创建方式也跟着变了。阅读源码时要对应自己使用的 JDK 版本，别拿 JDK 8 的源码去套 JDK 17 的行为。
第二，IntegerCache缓存的是对象引用，不是值。cache[k] = new Integer(j++)在类加载时就把这些对象建好了。所以如果你用反射去修改某个缓存对象内部的值，比如修改Integer的value字段，影响范围是全 JVM 的。这种操作极度危险，生产环境千万别碰，否则同一份代码在不同地方读到不一样的结果。
第三，-XX:AutoBoxCacheMax只影响IntegerCache的上界，不影响下界。下界永远是 -128，没有任何公开参数能改。除非你自己改 JDK 源码重新编译，但那已经是另一个故事了。
第四，Long也有缓存，范围是 -128 到 127，不可配置。Short、Byte的范围更特殊，因为它们的值域本身就小，全部值都在缓存范围内。Character缓存的是 0 到 127。这些都是同一套设计思想在不同包装类型上的体现。
第五，IDE 静态检查工具通常会对Integer类型的==比较给出警告，别无视这些警告。它们存在的意义就是帮你避开引用比较的坑。我见过一个线上事故，就是两个从缓存中取出的Integer在高并发下用==比较来判断状态是否一致，后来缓存范围一改、数据一旦超出范围，判断逻辑瞬间失效。排查了整整一天才定位到是这里的问题。
5.3 排查提醒：出现诡异“相等”问题先怀疑缓存
如果你在代码里看到类似这样的写法：
if (someMethod() == someOtherMethod()) { // 业务分支 }而这两个方法返回的是Integer类型，那这里就有隐患。==比较的是引用，当返回值都在缓存范围内时碰巧相等，一旦某个返回值超出范围，逻辑就变了。这种 bug 隐蔽性极强，因为小数据量测试完全正常，只有跑到特定数据范围才会炸。
排查这类问题的思路很简单：找到参与比较的变量类型，如果发现是包装类型且用了==，直接改成equals；如果变量来自valueOf、自动装箱或者容器解包，更要警惕。顺手看一眼IntegerCache.high的值有没有被 JVM 参数改过，也是个常规操作。
另外一个相关知识点是Integer的equals实现，它内部是先比较类型、再比较intValue()，所以用equals不存在缓存范围问题，永远按值比较。这也是我强烈推荐包装类型一律用equals的原因。
6. 写在最后：一个值得培养的习惯
我做 Java 几年，踩过不少包装类型相关的坑，最深的一条体会就是：遇到看似“两个方法都一样”的 API，一定要点进去看一眼源码，哪怕只花五分钟。Integer.parseInt和Integer.valueOf表面上的差异就一个字母，实际牵扯出的是装箱机制、缓存机制、JVM 参数、判等陷阱一整条知识链。
尤其是IntegerCache这套缓存设计，它本身是个很漂亮的性能优化，但任何性能优化一旦暴露成“隐式行为”，就会变成使用者的负担。你写了一个==，你以为你在比较值，实际上程序在比较地址，到底对不对全看缓存范围。这种心智负担是隐形的，只有出了 bug 才被人记起。
所以我最后再分享一个小建议：如果你们的代码库里有大量包装类型比较、转换的逻辑，花点时间统一梳理一遍，把==全部换成equals，把不必要的装箱全部去掉。这个工作不复杂，但能帮你避开未来很多线上问题。以后再看到parseInt和valueOf，也就不用纠结了：一个是纯粹的字符串解析，一个是解析完再附加一层缓存包装。搞清楚这一点，整条链路就都通了。
