前几天，有位小伙伴向我反馈，在维护代码过程中，出现了一个莫名其妙的问题。明明上线之后程序跑得还好好的，可程序上线运行一段时间之后，所有，代码没有做任何修改，发 cxccccc现运行结果和期望值恰好相反。因为涉及到金额造成了比较大的损失，最后，这位小伙伴还被公司辞退了，大家可以来评论一下，这位小伙伴背的这个锅值不值？
1、业务场景
大家来看，他的代码大致是这样写的：
一般情况下，a和b都输入100的时候，返回为true，但当a和b都输入1000的时候，返回为false。按照正常逻辑理解，100 等于等于 100，那1000 为什么不等于等于1000 呢？这位同学，百思不得其解。于是，这位同学，还特意写了一段测试代码
这到底是什么原因呢？我们对照Integer的源码来进行分析：
2、源码分析
我摘取了Integer的源码片段，它有一个valueOf()的方法：
我们可以看到，Integer源码中的valueOf()方法做了一个条件判断，其中 IntegerCache.low的值为-128，
IntegerCache.high的值为127。
也就是说如果目标值在-128～127之间，会直接从cache数组中取值，否则就会新建对象。
这里又有人会问了，那为什么默认是-128 - 127，怎么不是-200 - 200或者是其他值呢？那JDK为何要这样做呢？
在Java API 中是这样解释的：
Returns an Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values. This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range
大致意思是：
-128～127的数据在int范围内是使用最频繁的，为了减少频繁创建对象带来的内存消耗，这里其实是用到了享元模式，以提高空间和时间性能。
在JDK中，这样的应用不止int，我给小伙伴们整理了一个表格，表格中的其他类型也都应用了享元模式，也就是说对数值做了缓存，只是缓存的范围不一样，具体如表中所示：
我需要这张表的小伙伴可以私信我，以上就是关于Integer对象比较大小的分析，听懂了的小伙伴，请关注点个赞，下次不迷路。
如果大家还有其他疑问，请在评论区留言。如果本次面试解析对你有帮助，分享给更多的人。关注我，面试不再难！
需要学习路线图的同学可S我免费拿，还有10万+字面试文档！ 我是被编程耽误的文艺Tom，
