此文是我为自己拙著《.NET 4.0面向对象编程漫谈》所新写的扩大阅读资料。
本文触及到一些JVM原理和Java的字节码指令，引荐感兴味的读者阅读一本有关JVM的经典书籍《深化Java虚拟机(第2版)》，将它与我在《.NET 4.0面向对象编程漫谈》中引见的CLR原理与IL汇编指令作个对比，置信读者会有一定的启发。而仔细对比两个相似事物的异同，是很无效的学习方法之一。
今后我还将在个人博客上放出其他的文章，希望能帮助书的读者开拓视野，启发思考，大家一同探讨技术的奥秘。
本文所述之内容仅代表个人之理解，任何疏漏及错误请直接回贴指出。
1 奇特的顺序输出
前段时间，一个先生给我看了一段“十分诡异”的Java代码：
#div_code img{border:0px;}
Code highlighting produced by Actipro CodeHighlighter (freeware)CodeHighlighter/-->public class TestInteger {public static void main(String[] args){Integer v1=100;Integer v2=100;System.out.println(v1==v2); //输出：trueInteger w1=200;Integer w2=200;System.out.println(w1==w2); //输出：false}}
让这个先生最困惑的是，为什么这些如此相似的代码会有这样令人不测的输出?
我平时多使用C#，Java用得不多，初看到这段代码的输出，我也异样十分奇异：怎么会这样呢?100和200这两个整型数值对Integer这个类有本质上的差别吗?
为了弄明白出现上述景象的底层原因，我使用javap工具反汇编了Java编译器生成的.class文件：
通过仔细阅读Java编译器生的字节码，我发现以下给Integer变量赋值的语句：
Integer v1=100;
实际上调用的是Integer.valueOf方法。
而完成两个Integer变量比较的以下语句：
System.Console.WriteLine(v1 == v2);
实际生成的是if_acmpne指令。其中的a代表“address”，cmp代表“Compare”，ne代表“not equal”。
这条指令的含义是：比较Java方法栈中的两个操作数(即v1与v2)，看看它们是不是指向堆中的同一个对象。
当给v1和v2赋值100时，它们将引用同一个Integer对象。
那为什么当值改为200时，w1和w2就“翻脸了”，分别引用不同的Integer对象?
秘密就在于Integer.valueOf方法。幸运的是，Java的类库是开源的，所以我们可以毫不费力地看到相关的源代码：
#div_code img{border:0px;}
Code highlighting produced by Actipro CodeHighlighter (freeware)CodeHighlighter/-->public static Integer valueOf(int i) {if(i = -128 i = IntegerCache.high)return IntegerCache.cache[i + 128];elsereturn new Integer(i);}
一切真相大白，原来Integer在外部使用了一个私有的静态类IntegerCache，此类外部封装了一个Integer对象的cache数组来缓存Integer对象，其代码如下：
#div_code img{border:0px;}
Code highlighting produced by Actipro CodeHighlighter (freeware)CodeHighlighter/-->private static class IntegerCache {static final Integer cache[];//……}
再仔细看看IntegerCache外部的代码，会看到它使用静态初始化块在cache数组中保管了[-128,127]区间内的一共256个Integer对象。
当给Integer变量直接赋整数值时，假设这个数值位于[-128,127]内，JVM(Java Virtual Machine)就直接使用cache中缓存的Integer对象，否则，JVM会重新创建一个Integer对象。
一切真相大白。
2 进一步探究Integer
我们再进一步地看看这个幽默的Integer：
#div_code img{border:0px;}
Code highlighting produced by Actipro CodeHighlighter (freeware)CodeHighlighter/--> Integer v1 = 500;Integer v2 = 300;Integer addResult = v1 + v2; //结果：800double divResult = (double)v1/v2; //结果：1.6666666666666667
哟，居然Integer对象支持加减乘除运算耶!它是怎么做到的?
再次使用javap反汇编.class文件，不难发现：
Integer类的外部有一个私有int类型的字段value，它代表了Integer对象所“封装”的整数值。
private final int value;
当需要执行v1+v2时，JVM会调用v1和v2两个Integer对象的intValue方法取出其外部所封装的整数值value，然后调用JVM直接支持的iadd指令将这两个整数直接相加，结果送回方法栈中，然后调用Integer.valueOf方法转换为Integer对象，让addResult变量引用这一对象。
除规律复杂一点，JVM先调用i2d指令将int转换为double，然后再调用ddiv指令完成浮点数相除的工作。
通过上述分析，我们可以知道，其实Integer类本身并不支持加减乘除，而是由Java编译器将这些加减乘除的语句转换为JVM可以直接执行的字节码指令(比如本例中用到的iadd和ddiv)，其中会添加许多条用于类型转换的语句。
由此可见，与原始数据类型int相比，使用Integer对象直接停止加减乘除会带来较低的运行性能，应避免使用。
3 JDK中Integer类的“弯弯绕”设计方案
现在，我们站在一个更高的角度，探讨一下Integer的设计。
我个人认为，给Integer类型添加一个“对象缓冲”不是一个好的设计，从最后面的示例代码大家一定会感到这一设计给使用层的代码带来了一定的混乱。另外，我们看到JDK设计者只缓存了[-128,127]共256个Integer对象，他能够认为这个区间内的整数是最常用的，所以应该缓存以提升性能。就我来看，这未免有点过于“自以为是”了，说这个区间内的Integer对象用得最多有什么依据?关于那些经常处理128的整数值的使用顺序而言，这个缓存一点用处也没有，是个累赘。就算真要缓存，那也最好由使用顺序开发者自己来实现，由于他可以依据自己开发的实际情况缓存真正用到的对象，而不需背着这个包容着256个Integer对象的大包袱。
而且后面也看到了，基于Integer对象的加减乘除会增加许多不必要的类型转换指令，远不如直接使用原始数据类型更快捷更牢靠。
其实上用得最多的不是Integer对象而是它所封装的一堆静态方法(这些方法提供了诸如类型转换等常用功用)，我很怀疑在实际开发中有多少场所需要去创建少量的Integer对象，而且还假设它们封装的数值还位于[-128,127]区间之内?
缓存Integer对象还对多线程使用顺序带来了一定的风险，由于能够会有多个线程同时存取同一个缓存了的Integer对象。不过JDK设计者曾经考虑到了这个问题，我看到Integer类的字段都是final的，不可改，是一个不可变类，所以可以在多线程环境下平安地访问。虽然在使用上没问题，但这一切是不是有点弯弯绕?去掉这个对象缓存，Integer类型是不是“更轻爽”“更好用”?
4 C# int应战Java Integer
将Java的设计与.NET(以C#为例)的设计作个比较是幽默的。
Java将数据类型分为“原始数据类型”和“引用数据类型”两大类，int是原始数据类型，为了向开发者提供一些常用的功用(比如将String转换为int)，所以JDK提供了一个引用类型Integer，封装这些功用。
.NET则不一样，它的数据类型分为“值类型”和“引用数据类型”两大类，int属于值类型，本身就拥有丰厚的方法，请看以下C#代码：
#div_code img{border:0px;}
Code highlighting produced by Actipro CodeHighlighter (freeware)CodeHighlighter/-->int i = 100;string str = i.ToString(); //int变量本身就拥有“一堆”的方法
使用.NET的反汇编器ildasm检查一下上述代码生成的IL指令，不难发现C#编译器会将int类型映射为System.Int32结构：
留意System.Int32是一个值类型，生活于线程堆栈中，普通来说，在多线程环境下，使用值类型的变量往往比引用类型的变量更平安，由于它减少了多线程访问同一对象所带来的问题。
扼要解释一下：请对比以下两个方法：
void DoSomethingWithValueType(int value);
void DoSomethingWithReferenceType(MyClass obj);
当多个线程同时执行上述两个方法时，线程函数使用值类型的参数value是比较平安的，不必担心多个线程互相影响，但引用类型的obj参数就要小心了，假设多个线程接纳到的obj参数有能够引用同一个MyClass对象，为保证运行结果的正确，有能够需要给此对象加锁。
与JVM一样，.NET的CLR也提供了add等专用指令完成加减乘除功用。
从开发者使用角度而言，C#的int既具有与Java的原始数据类型int一样的在虚拟机级别的专用指令，又具有Java包装类Integer所拥有的一些功用，还同时避免了Java中Integer的那种比较乖僻的特性，个人认为，C#中的int比Java中的int/Integer更好用，更易用。
但从探究技术内幕而言则大不一样，Java使用Integer一个类就“搞定”了所有常用的整数处理功用，而关于.NET的System.In32结构，猎奇的同学无妨用Reflector去检查一下相关的源码，会发现System.Int32在外部许多地方使用了Number类所封装的功用，还用到了NumberFormatInfo(提供数字的格式化信息)、CultureInfo(提供以后文明信息)等相关类型，假设再算加上一堆的接口，那真是“相外地”复杂。
比对一下Java平台与.NET平台，往往会发现在许多地方Java封装得较少。
从使用顺序开发角度来看，不少地方Java在使用上不如.NET方便。就拿本文所触及的十分常见的整数类型及其运算而言，置信大家都看到了，使用Java编程需要留心这个“Intege对象缓存”的陷阱，而.NET则很贴心地把这些已发现的陷阱(.NET设计者说：当然肯定会有没发现的陷阱，但那就不关我事了)都盖上了“厚厚”的井盖，让开发者很省心，因而带来了较高的开发效率和较好的开发体验。
但另一方面，Java的JDK代码一览有余，是开放的，你要探究其技术内幕，总是很方便，这点还是比较让人放心。
.NET则相对比较封锁，总是遮遮掩掩，想一览其庐山真相还真不容易，而且我感觉它为开发者考虑得太周到了，效劳得太好了，这不见得是一件坏事。由于兽性的弱点之一就是“好逸恶劳”，生活太舒适了，进取肉体就会少掉不少，.NET开发者很容易于不知不觉中养成了对技术不求甚解的“恶习”，由于既然代码可以正常工作，那又何必费心地去追根问底?但话又说回来，假设仅满足于知其然，又怎会在技术上有所进步和进步?等到年纪一大，就被年轻人给淘汰了。而这种景象的出现，到底应该怪微软，怪周遭的环境，还是自己呢?文章由
马克华菲官方旗舰店整理，收集辛苦，希望能保留出处，谢谢斑竹大哥。
