Xeon_CC的博客

分析过程：Integer i1 = 100;先看看常量池里面有没有100，如果没有100，新建一个，如果有，直接引用。Integer I2 = new Integer(100);直接在堆内存申请一个新的内存空间，值为100，这时候，i1 和 i2 的内存地址就不一样了int i3 = 100;发现常量池已经出现过100了，直接拿来引用，所以 i1 == i3 结果为true，引用的地址是一样的。Integer i4 = Integer.valueOf(100);把int类型.

内存溢出（OOM）内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。 由于GC一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现OOM的情况。 大多数情况下，GC会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的Full GC操作，这时候会回收大量的内存，供应用程序继续使用。 javadoc中堆OutOfMemoryError的解释是，没有空闲的内存，并且垃圾收集器也无

现有的主流JVM分别是HotSpot和JRockit，主要研究对象也是这两个。这篇文章里，我们只研究HotSpot，也就是所谓的Sun JVM。目前阶段，Sun的GC方式主要有CMS和G1两种。考虑到效果和实际应用，这里只介绍CMS。CMS，全称Concurrent Mark Sweep，是JDK1.4后期版本开始引入的新GC算法，在JDK5和JDK6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求较高的应用，并且预期这部分应用能够承受垃圾回收线程和应用线程共享处理器资源，且应用中存在比较多的长

System.gc( ) 的理解在默情况下，通过System.gc( )或者Runtime.getRuntime( ).gc( )的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存 然而System.gc( ) 调用附带一个免责声明，无法保证堆垃圾收集器的调用。 JVM实现着可以通过System.gc( ) 调用来决定JVM的GC行为。而一般情况下，垃圾回收应该是自动进行的，无需手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写一个性能基准，我.

类的加载过程（整体环节） 加载阶段Loading：① 通过一个类的全限定名获取定义此类的二进制字节流② 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构③ 在内存中生成代表这个类的java.lang.Class 对象，作为方法区这个类的各种数据的访问入口链接阶段Linking：① 验证（Verify）：目的在于确保Class文件的字节流中包含信附和当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。 主要包括四种验证，文件格式验证，元数据验证...

类加载子系统的作用 ①类加载子系统负责从文件系统或者网络中加载class文件，class文件在文件开头有特定的文件标识。②ClassLoader只负责class文件加载，至于它是否可以运行，则由于Execution Engine 决定③加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射） 类加载器ClassLoader角色 ① cla...