前几天，有位小伙伴向我反馈，在维护代码过程中，出现了一个莫名其妙的问题。明明上线之后程序跑得还好好的，可程序上线运行一段时间之后，所有，代码没有做任何修改，发 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对象比较大小的分析
