java 内存区域及存放内容

1、程序计数器：

程序执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能都需要依赖程序计数器完成。

2、栈

主要存储的是：局部变量表、操作栈、动态链接、方法出口等 信息

局部变量表：存放的是编译器可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用、returnAddress类型

操作数栈：和局部变量区一样，操作数栈也是被组织成一个以字长为单位的数组。但是和前者不同的是，它不是通过索引来访问，而是通过标准的栈操作—压栈和出栈—来访问的。比如，如果某个指令把一个值压入到操作数栈中，稍后另一个指令就可以弹出这个值来使用。       虚拟机在操作数栈中存储数据的方式和在局部变量区中是一样的：如int、long、float、double、reference和returnType的存储。对于byte、short以及char类型的值在压入到操作数栈之前，也会被转换为int。       虚拟机把操作数栈作为它的工作区——大多数指令都要从这里弹出数据，执行运算，然后把结果压回操作数栈。比如，iadd指令就要从操作数栈中弹出两个整数，执行加法运算，其结果又压回到操作数栈中，看看下面的示例，它演示了虚拟机是如何把两个int类型的局部变量相加，再把结果保存到第三个局部变量的：

3、本地方法栈

对于一个运行中的Java程序而言，它还可能会用到一些跟本地方法相关的数据区。当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。本地方法可以通过本地方法接口来访问虚拟机的运行时数据区，但不止如此，它还可以做任何它想做的事情。 　　本地方法本质上时依赖于实现的，虚拟机实现的设计者们可以自由地决定使用怎样的机制来让Java程序调用本地方法。 　　任何本地方法接口都会使用某种本地方法栈。当线程调用Java方法时，虚拟机会创建一个新的栈帧并压入Java栈。然而当它调用的是本地方法时，虚拟机会保持Java栈不变，不再在线程的Java栈中压入新的帧，虚拟机只是简单地动态连接并直接调用指定的本地方法。 　　如果某个虚拟机实现的本地方法接口是使用C连接模型的话，那么它的本地方法栈就是C栈。当C程序调用一个C函数时，其栈操作都是确定的。传递给该函数的参数以某个确定的顺序压入栈，它的返回值也以确定的方式传回调用者。同样，这就是虚拟机实现中本地方法栈的行为。 　　很可能本地方法接口需要回调Java虚拟机中的Java方法，在这种情况下，该线程会保存本地方法栈的状态并进入到另一个Java栈。 　　下图描绘了这样一个情景，就是当一个线程调用一个本地方法时，本地方法又回调虚拟机中的另一个Java方法。 　　这幅图展示了JAVA虚拟机内部线程运行的全景图。一个线程可能在整个生命周期中都执行Java方法，操作它的Java栈；或者它可能毫无障碍地在Java栈和本地方法栈之间跳转。　 该线程首先调用了两个Java方法，而第二个Java方法又调用了一个本地方法，这样导致虚拟机使用了一个本地方法栈。假设这是一个C语言栈，其间有两个C函数，第一个C函数被第二个Java方法当做本地方法调用，而这个C函数又调用了第二个C函数。之后第二个C函数又通过本地方法接口回调了一个Java方法（第三个Java方法），最终这个Java方法又调用了一个Java方法（它成为图中的当前方法）。

4、堆

Java 堆内存 堆内存 Java 中的堆是 JVM 所管理的最大的一块内存空间，主要用于存放各种类的实例对象。 在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor。 这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。 堆的内存模型大致为： 从图中可以看出： 堆大小 = 新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。 本人使用的是 JDK1.6，以下涉及的 JVM 默认值均以该版本为准。 默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )，即：新生代 ( Young ) = 1/3 的堆空间大小。 老年代 ( Old ) = 2/3 的堆空间大小。其中，新生代 ( Young ) 被细分为 Eden 和 两个 Survivor 区域，这两个 Survivor 区域分别被命名为 from 和 to，以示区分。 默认的，Edem : from : to = 8 : 1 : 1 ( 可以通过参数 –XX:SurvivorRatio 来设定 )，即： Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小。 JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。 因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。 GC 堆 Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种：Minor GC、Full GC ( 或称为 Major GC )。 Minor GC 是发生在新生代中的垃圾收集动作，所采用的是复制算法。 新生代几乎是所有 Java 对象出生的地方，即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部分对象通常不需长久存活，具有朝生夕灭的性质。 当一个对象被判定为 "死亡" 的时候，GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的频繁区域。 当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳 ( 上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定 )，这些对象就会成为老年代。 但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。 Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。 现实的生活中，老年代的人通常会比新生代的人 "早死"。堆内存中的老年代(Old)不同于这个，老年代里面的对象几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 "死掉" 了的。因此，Full GC 发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。 另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。 GC 日志 public  static  void main(String[] args) {     Object obj =  new Object();     System.gc();     System.out.println();     obj =  new Object();     obj =  new Object();     System.gc();     System.out.println(); } 设置 JVM 参数为 -XX:+PrintGCDetails，使得控制台能够显示 GC 相关的日志信息，执行上面代码，下面是其中一次执行的结果。 Full GC 信息与 Minor GC 的信息是相似的，这里就不一个一个的画出来了。 从 Full GC 信息可知，新生代可用的内存大小约为 18M，则新生代实际分配得到的内存空间约为 20M(为什么是 20M? 请继续看下面...)。老年代分得的内存大小约为 42M，堆的可用内存的大小约为 60M。可以计算出： 18432K ( 新生代可用空间 ) + 42112K ( 老年代空间 ) = 60544K ( 堆的可用空间 ) 新生代约占堆大小的 1/3，老年代约占堆大小的 2/3。也可以看出，GC 对新生代的回收比较乐观，而对老年代以及方法区的回收并不明显或者说不及新生代。 并且在这里 Full GC 耗时是 Minor GC 的 22.89 倍。 JVM 参数选项 jvm 可配置的参数选项可以参考 Oracle 官方网站给出的相关信息： http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 下面只列举其中的几个常用和容易掌握的配置选项：  1   /**  2    -Xms60m  3    -Xmx60m  4    -Xmn20m  5    -XX:NewRatio=2 ( 若 Xms = Xmx, 并且设定了 Xmn, 那么该项配置就不需要配置了 )  6    -XX:SurvivorRatio=8  7    -XX:PermSize=30m  8    -XX:MaxPermSize=30m  9    -XX:+PrintGCDetails 10     */ 11   public   static   void  main(String[] args) { 12       new  Test().doTest(); 13  } 14   15   public   void  doTest(){ 16      Integer M =  new  Integer(1024 * 1024 * 1);   // 单位, 兆(M) 17        byte [] bytes =  new   byte [1 * M];  // 申请 1M 大小的内存空间 18       bytes =  null ;   // 断开引用链 19       System.gc();    // 通知 GC 收集垃圾 20       System.out.println(); 21      bytes =  new   byte [1 * M];   // 重新申请 1M 大小的内存空间 22       bytes =  new   byte [1 * M];   // 再次申请 1M 大小的内存空间 23       System.gc(); 24      System.out.println(); 25  } 按上面代码中注释的信息设定 jvm 相关的参数项，并执行程序，下面是一次执行完成控制台打印的结果： [ GC [ PSYoungGen:  1351K -> 288K (18432K) ]  1351K -> 288K (59392K), 0.0012389 secs ]  [ Times: user=0.00 sys=0.00, real=0.00 secs ]  [ Full GC (System)  [ PSYoungGen:  288K -> 0K (18432K) ]  [ PSOldGen:  0K -> 160K (40960K) ]  288K -> 160K (59392K)  [ PSPermGen:  2942K -> 2942K (30720K) ],  0.0057649 secs ] [ Times:  user=0.00  sys=0.00,  real=0.01 secs ]  [ GC [ PSYoungGen:  2703K -> 1056K (18432K) ]  2863K -> 1216K(59392K),  0.0008206 secs ]  [ Times: user=0.00 sys=0.00, real=0.00 secs ]  [ Full GC (System)  [ PSYoungGen:  1056K -> 0K (18432K) ]  [ PSOldGen:  160K -> 1184K (40960K) ]  1216K -> 1184K (59392K)  [ PSPermGen:  2951K -> 2951K (30720K) ], 0.0052445 secs ]  [ Times: user=0.02 sys=0.00, real=0.01 secs ]  Heap  PSYoungGen      total 18432K, used 327K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)   eden space 16384K, 2% used [0x00000000fec00000,0x00000000fec51f58,0x00000000ffc00000)   from space 2048K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x0000000100000000)   to   space 2048K, 0% used [0x00000000ffc00000,0x00000000ffc00000,0x00000000ffe00000)  PSOldGen        total 40960K, used 1184K [0x00000000fc400000, 0x00000000fec00000, 0x00000000fec00000)   object space 40960K, 2% used [0x00000000fc400000,0x00000000fc5281f8,0x00000000fec00000)  PSPermGen       total 30720K, used 2959K [0x00000000fa600000, 0x00000000fc400000, 0x00000000fc400000)   object space 30720K, 9% used [0x00000000fa600000,0x00000000fa8e3ce0,0x00000000fc400000) 从打印结果可以看出，堆中新生代的内存空间为 18432K ( 约 18M )，eden 的内存空间为 16384K ( 约 16M)，from / to survivor 的内存空间为 2048K ( 约 2M)。 这里所配置的 Xmn 为 20M，也就是指定了新生代的内存空间为 20M，可是从打印的堆信息来看，新生代怎么就只有 18M 呢? 另外的 2M 哪里去了?  别急，是这样的。新生代 = eden + from + to = 16 + 2 + 2 = 20M，可见新生代的内存空间确实是按 Xmn 参数分配得到的。 而且这里指定了 SurvivorRatio = 8，因此，eden = 8/10 的新生代空间 = 8/10 * 20 = 16M。from = to = 1/10 的新生代空间 = 1/10 * 20 = 2M。 堆信息中新生代的 total 18432K 是这样来的： eden + 1 个 survivor = 16384K + 2048K = 18432K，即约为 18M。 因为 jvm 每次只是用新生代中的 eden 和 一个 survivor，因此新生代实际的可用内存空间大小为所指定的 90%。 因此可以知道，这里新生代的内存空间指的是新生代可用的总的内存空间，而不是指整个新生代的空间大小。 另外，可以看出老年代的内存空间为 40960K ( 约 40M )，堆大小 = 新生代 + 老年代。因此在这里，老年代 = 堆大小 - 新生代 = 60 - 20 = 40M。 最后，这里还指定了 PermSize = 30m，PermGen 即永久代 ( 方法区 )，它还有一个名字，叫非堆，主要用来存储由 jvm 加载的类文件信息、常量、静态变量等。 打个盹，回到 doTest() 方法中，可以看到代码在第 17、21、22 这三行中分别申请了一块 1M 大小的内存空间，并在 19 和 23 这两行中分别显式的调用了 System.gc()。从控制台打印的信息来看，每次调 System.gc()，是先进行 Minor GC，然后再进行 Full GC。 第 19 行触发的 Minor GC 收集分析： 从信息 PSYoungGen :  1351K -> 288K，可以知道，在第 17 行为 bytes 分配的内存空间已经被回收完成。 引起 GC 回收这 1M 内存空间的因素是第 18 行的 bytes = null;   bytes 为 null 表明之前申请的那 1M 大小的内存空间现在已经没有任何引用变量在使用它了， 并且在内存中它处于一种不可到达状态 ( 即没有任何引用链与 GC Roots 相连 )。那么，当 Minor GC 发生的时候，GC 就会来回收掉这部分的内存空间。 第 19 行触发的 Full GC 收集分析： 在 Minor GC 的时候，信息显示 PSYoungGen :  1351K -> 288K，再看看 Full GC 中显示的 PSYoungGen :  288K -> 0K，可以看出，Full GC 后，新生代的内存使用变成 0K 了 ( 0K，零 K，有没有人看成是英文的 OK 的 ? 好吧。我承认我第一次看的时候以为是英文的 OK，当时还特意在控制台打印 0K 和 OK 来确认。最后发现英文的 O 长得比阿拉伯数字的 0 要丰满和胖一些。现在印象还是比较深刻的。好像。。我跑题了 ~~ ) 刚刚说到 Full GC 后，新生代的内存使用从 288K 变成 0K 了，那么这 288K 到底哪去了 ? 难道都被 GC 当成垃圾回收掉了 ? 当然不是了。我还特意在 main 方法中 new 了一个 Test 类的实例，这里的 Test 类的实例属于小对象，它应该被分配到新生代内存当中，现在还在调用这个实例的 doTest 方法呢，GC 不可能在这个时候来回收它的。 接着往下看 Full GC 的信息，会发现一个很有趣的现象，PSOldGen:  0K  -> 160K，可以看到，Full GC 后，老年代的内存使用从 0K 变成了 160K，想必你已经猜到大概是怎么回事了。当 Full GC 进行的时候，默认的方式是尽量清空新生代 ( YoungGen )，因此在调 System.gc() 时，新生代 ( YoungGen ) 中存活的对象会提前进入老年代。 第 23 行触发的 Minor GC 收集分析： 从信息 PSYoungGen :  2703K -> 1056K，可以知道，在第 21 行创建的，大小为 1M 的数组被 GC 回收了。在第 22 行创建的，大小也为 1M 的数组由于 bytes 引用变量还在引用它，因此，它暂时未被 GC 回收。  第 23 行触发的 Full GC 收集分析： 在 Minor GC 的时候，信息显示 PSYoungGen :  2703K -> 1056K，Full GC 中显示的 PSYoungGen :  1056K -> 0K，以及 PSOldGen:  160K -> 1184K，可以知道，新生代 ( YoungGen ) 中存活的对象又提前进入老年代了。

5、方法区

最近在看《深入理解Java虚拟机》，书中给了几个例子，比较好的说明了几种OOM（OutOfMemory）产生的过程，大部分的程序员在写程序时不会太关注Java运行时数据区域的结构： 感觉有必要通过几个实在的例子来加深对这几个区域的了解 1）Java堆 所有对象的实例分配都在Java堆上分配内存，堆大小由-Xmx和-Xms来调节，sample如下所示： [java]  view plain  copy public class HeapOOM {              static class OOMObject{}          /**       * @param args       */       public static void main(String[] args) {           List<OOMObject> list = new ArrayList<OOMObject>();                      while(true){               list.add(new OOMObject());           }       }      }   加上JVM参数-verbose:gc -Xms10M -Xmx10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+HeapDumpOnOutOfMemoryError，就能很快报出OOM： Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 并且能自动生成Dump。 2）方法区 方法区是存放虚拟机加载类的相关信息，如类、静态变量和常量，大小由-XX:PermSize和-XX:MaxPermSize来调节，类太多有可能撑爆永久带： [java]  view plain  copy public class MethodAreaOOM {              static class OOMOjbect{}          /**       * @param args       */       public static void main(String[] args) {           // TODO Auto-generated method stub           while(true){               Enhancer eh = new Enhancer();               eh.setSuperclass(OOMOjbect.class);               eh.setUseCache(false);               eh.setCallback(new MethodInterceptor(){                      @Override                   public Object intercept(Object arg0, Method arg1,                           Object[] arg2, MethodProxy arg3) throws Throwable {                       // TODO Auto-generated method stub                       return arg3.invokeSuper(arg0, arg2);                   }                                  });               eh.create();           }       }      }   加上永久带的JVM参数：-XX:PermSize=10M -XX:MaxPermSize=10M，运行后会报如下异常： Exception in thread "main" java.lang.OutOfMemoryError: PermGen space 静态变量或常量也会有可能撑爆方法区： [java]  view plain  copy public class ConstantOOM {          /**       * @param args       */       public static void main(String[] args) {           // TODO Auto-generated method stub           List<String> list = new ArrayList<String>();           int i=0;           while(true){               list.add(String.valueOf(i++).intern());           }       }      }   同样加上JVM参数：-XX:PermSize=10M -XX:MaxPermSize=10M，运行后报如下异常： Exception in thread "main" java.lang.OutOfMemoryError: PermGen space 3）Java栈和本地方法栈 栈是存放线程调用方法时存储局部变量表，操作，方法出口等与方法执行相关的信息，栈大小由Xss来调节，方法调用层次太多会撑爆这个区域，samples如下所示： [java]  view plain  copy package com.cutesource;      public class StackOOM {          /**       * @param args       */              private int stackLength = 1;              public void stackLeak(){           stackLength++;           stackLeak();       }              public static void main(String[] args) throws Throwable{           // TODO Auto-generated method stub           StackOOM oom = new StackOOM();           try{               oom.stackLeak();           }catch(Throwable err){               System.out.println("Stack length:" + oom.stackLength);               throw err;           }                  }      }   设置JVM参数：-Xss128k，报出异常： Exception in thread "main" java.lang.StackOverflowError 打印出Stack length:1007，这里可以看出，在我的机器上128k的栈容量能承载深度为1007的方法调用。当然报这样的错很少见，一般只会出现无限循环的递归中，另外，线程太多也会占满栈区域： [java]  view plain  copy package com.cutesource;      public class StackOOM {          /**       * @param args       */              private int stackLength = 1;              private void dontStop(){           while(true){               try{Thread.sleep(1000);}catch(Exception err){}           }       }              public void stackLeakByThread(){           while(true){               Thread t = new Thread(new Runnable(){                      @Override                   public void run() {                       // TODO Auto-generated method stub                       dontStop();                   }                                  });               t.start();               stackLength++;           }       }              public static void main(String[] args) throws Throwable{           // TODO Auto-generated method stub           StackOOM oom = new StackOOM();           try{               oom.stackLeakByThread();           }catch(Throwable err){               System.out.println("Stack length:" + oom.stackLength);               throw err;           }                  }      }   报出异常：Exception in thread "main" java.lang.OutOfMemoryError:unable to create new native thread 不过在windows上运行这个例子要小心，会出现系统假死的情况，有可能需要重启机器才行。 以上几个例子虽然比较简单，但能很好帮助普通的程序员更加直观的了解 Java堆， 方法区， Java栈和本地方法栈。

6、运行事常量池

在class文件中，“常量池”是最复杂也最值得关注的内容。 　　Java是一种动态连接的语言，常量池的作用非常重要，常量池中除了包含代码中所定义的各种基本类型（如int、long等等）和对象型（如String及数组）的常量值还，还包含一些以文本形式出现的符号引用，比如： 　　类和接口的全限定名； 　　字段的名称和描述符； 　　方法和名称和描述符。 　　在C语言中，如果一个程序要调用其它库中的函数，在连接时，该函数在库中的位置（即相对于库文件开头的偏移量）会被写在程序中，在运行时，直接去这个地址调用函数； 　　而在Java语言中不是这样，一切都是动态的。编译时，如果发现对其它类方法的调用或者对其它类字段的引用的话，记录进class文件中的，只能是一个文本形式的符号引用，在连接过程中，虚拟机根据这个文本信息去查找对应的方法或字段。 　　所以，与Java语言中的所谓“常量”不同，class文件中的“常量”内容很非富，这些常量集中在class中的一个区域存放，一个紧接着一个，这里就称为“常量池”。 java中的常量池技术，是为了方便快捷地创建某些对象而出现的，当需要一个对象时，就可以从池中取一个出来（如果池中没有则创建一个），则在需要重复重复创建相等变量时节省了很多时间。常量池其实也就是一个内存空间，不同于使用new关键字创建的对象所在的堆空间。本文只从java使用者的角度来探讨java常量池技术，并不涉及常量池的原理及实现方法。个人认为，如果是真的专注java,就必须对这些细节方面有一定的了解。但知道它的原理和具体的实现方法则不是必须的。 常量池中对象和堆中的对象 [java]  view plain  copy public class Test{      Integer i1=new Integer(1);      Integer i2=new Integer(1);   //i1,i2分别位于堆中不同的内存空间         System.out.println(i1==i2);//输出false            Integer i3=1;      Integer i4=1;   //i3,i4指向常量池中同一个内存空间         System.out.println(i3==i4);//输出true      //很显然，i1,i3位于不同的内存空间      System.out.println(i1==i3);//输出false      }   8种基本类型的包装类和对象池 java中基本类型的包装类的大部分都实现了常量池技术，这些类是Byte,Short,Integer,Long,Character,Boolean,另外两种浮点数类型的包装类则没有实现。另外Byte,Short,Integer,Long,Character这5种整型的包装类也只是在对应值小于等于127时才可使用对象池，也即对象不负责创建和管理大于127的这些类的对象。以下是一些对应的测试代码： [java]  view plain  copy public class Test{      public static void main(String[] args){         //5种整形的包装类Byte,Short,Integer,Long,Character的对象，         //在值小于127时可以使用常量池         Integer i1=127;         Integer i2=127;         System.out.println(i1==i2)//输出true         //值大于127时，不会从常量池中取对象         Integer i3=128;         Integer i4=128;         System.out.println(i3==i4)//输出false         //Boolean类也实现了常量池技术         Boolean bool1=true;         Boolean bool2=true;         System.out.println(bool1==bool2);//输出true         //浮点类型的包装类没有实现常量池技术         Double d1=1.0;         Double d2=1.0;         System.out.println(d1==d2)//输出false             }      }   String也实现了常量池技术 String类也是java中用得多的类，同样为了创建String对象的方便，也实现了常量池的技术,测试代码如下: [java]  view plain  copy public class Test{      public static void main(String[] args){      //s1,s2分别位于堆中不同空间      String s1=new String("hello");      String s2=new String("hello");      System.out.println(s1==s2)//输出false      //s3,s4位于池中同一空间      String s3="hello";      String s4="hello";      System.out.println(s3==s4);//输出true      }      }   最后 细节决定成败，写代码更是如此。 在JDK5.0之前是不允许直接将基本数据类型的数据直接赋值给其对应地包装类的，如：Integer i = 5;  但是在JDK5.0中支持这种写法，因为编译器会自动将上面的代码转换成如下代码：Integer i=Integer.valueOf(5);   这就是Java的装箱.JDK5.0也提供了自动拆箱. Integer i =5;  int j = i;   Integer的封装： [java]  view plain  copy public static Integer valueOf(int i) {         final int offset = 128;         if (i >= -128 && i <= 127) { // must cache              return IntegerCache.cache[i + offset];         }           return new Integer(i);      }               private static class IntegerCache {                        private IntegerCache(){}     static final Integer cache[] = new Integer[-(-128) + 127 + 1];         static {             for(int i = 0; i < cache.length; i++)             cache[i] = new Integer(i - 128);         }     }     由于cache[]在IntegerCache类中是静态数组，也就是只需要初始化一次，即static｛......｝部分，所以，如果Integer对象初始化时是-128~127的范围，就不需要再重新定义申请空间，都是同一个对象---在IntegerCache.cache中，这样可以在一定程度上提高效率。 参考信息： http://blog.csdn.net/cutesource/article/details/8244250 http://blog.csdn.net/sunshine__me/article/details/49992909 http://blog.csdn.net/olanlanxiari/article/details/8104505