yingfeng2oo8的专栏

Java虚拟机可以有两种不同方法来区别活动对象和垃圾: 引用计数(Reference Counting)和跟踪(Tracing)。1. 采用Reference Counting的垃圾回收器对于采用Reference Counting的垃圾回收器，系统为堆上每一个对象都维护一个计数器，当一个对象被创建并且被引用时，这个计数就被置为1。当有新的变量引用该对象，计数器进行自加运算。当一个引用超出

按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给 自己用的，所以方法区、JVM内部处理或优化所需的内存(如

JVM里的GC(Garbage Collection)的算法有很多种，如标记清除收集器，压缩收集器，分代收集器等等,详见HotSpot VM GC 的种类       现在比较常用的是分代收集（generational collection,也是SUN VM使用的,J2SE1.2之后引入），即将内存分为几个区域，将不同生命周期的对象放在不同区域里:young generation，tenu

不管是YGC还是Full GC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同

java application项目（非web项目）改进前：-Xms128m-Xmx128m-XX:NewSize=64m-XX:PermSize=64m-XX:+UseConcMarkSweepGC-XX:CMSInitiatingOccupancyFraction=78-XX:ThreadStackSize=128-Xloggc:logs/gc.log-Dsun.rmi.dgc

前几篇篇文章介绍了介绍了JVM的参数设置并给出了一些生产环境的JVM参数配置参考方案。正如之前文章中提到的JVM参数的设置需要根据应用的特性来进行设置，每个参数的设置都需要对JVM进行长时间的监测，并不断进行调整才能找到最佳设置方案。本文将介绍如果通过工具及Java api来监测JVM的运行状态,并详细介绍各工具的使用方法。       需要监测的数据：(内存使用情况 谁使用了内存 GC的

工作中碰到过这个问题好几次了，觉得有必要总结一下，所以有了这篇文章，这篇文章分为三个部分：认识问题、分析问题、解决问题。一、认识问题:首先我们通过下面这个 测试程序 来认识这个问题： 运行的环境 （有必要说明一下，不同环境会有不同的结果）：32位 Windows XP，Sun JDK 1.6.0_18， eclipse 3.4， 测试程序： Java代码 收藏代码import java.ut

最近在应用服务器跑压力测试过程当中，出现无法创建线程的错误。在java应用中，有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大

相信有一定java开发经验的人或多或少都会遇到OutOfMemoryError的问题，这个问题曾困扰了我很长时间，随着解决各类问题经验的积累以及对问题根源的探索，终于有了一个比较深入的认识。在解决java内存溢出问题之前，需要对jvm（java虚拟机）的内存管理有一定的认识。jvm管理的内存大致包括三种不同类型的内存区域：PermanentGeneration space（永久保存区域）、He

一.Java虚拟机管理内存包括以下几个运行时数据区域：1.程序计数器2.java虚拟机栈3.本地方法栈4.java堆（其中java堆划分为年轻带、老年代）5.方法区（java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做非堆，目的应该是与java堆区分开来。    很多人都更愿意把方法区称为“永久代”，本质上两者并不等价）二.常见OOM异常

Java虚拟机（JVM）参数配置说明 在Java、J2EE大型应用中，JVM非标准参数的配置直接关系到整个系统的性能。JVM非标准参数指的是JVM底层的一些配置参数，这些参数在一般开发中默认即可，不需要任何配置。但是在生产环境中，为了提高性能，往往需要调整这些参数，以求系统达到最佳新能。另外这些参数的配置也是影响系统稳定性的一个重要因素，相信大多数Java开发人员都

java -Xmx1024m -version

最近在看《深入理解Java虚拟机》，书中给了几个例子，比较好的说明了几种OOM（OutOfMemory）产生的过程，大部分的程序员在写程序时不会太关注Java运行时数据区域的结构：感觉有必要通过几个实在的例子来加深对这几个区域的了解1）Java堆所有对象的实例分配都在Java堆上分配内存，堆大小由-Xmx和-Xms来调节，sample如下所示：

从Java平台的逻辑结构上来看，我们可以从下图来了解JVM：从上图能清晰看到Java平台包含的各个逻辑模块，也能了解到JDK与JRE的区别对于JVM自身的物理结构，我们可以从下图鸟瞰一下：对于JVM的学习，在我看来这么几个部分最重要：Java代码编译和执行的整个过程JVM内存管理及垃圾回收机制下面将这两个部分进行详细学习

Java代码编译是由Java源码编译器来完成，流程图如下所示：Java字节码的执行是由JVM执行引擎来完成，流程图如下所示： Java代码编译和执行的整个过程包含了以下三个重要的机制：Java源码编译机制类加载机制类执行机制Java源码编译机制Java 源码编译由以下三个过程组成：分析和输入到符号表注解处理语义分析和生成cla

JVM内存组成结构JVM栈由堆、栈、本地方法栈、方法区等部分组成，结构图如下所示：1）堆所有通过new创建的对象的内存都在堆中分配，其大小可以通过-Xmx和-Xms来控制。堆被划分为新生代和旧生代，新生代又被进一步划分为Eden和Survivor区，最后Survivor由From Space和To Space组成，结构图如下所示：新生代。新建的对象都是用新生代分配内存，

首先需要注意的是在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存，这个数值不能准确的反应堆内存的真实占用情况，因为GC过后这个值是不会变化的，因此内存调优的时候要更多地使用JDK提供的内存查看工具，比如JConsole和Java VisualVM。对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数，过多的GC和Full GC是会占用很多的系统资源

1． Java堆中各代分布：图1：Java堆中各代分布Young：主要是用来存放新生的对象。Old：主要存放应用程序中生命周期长的内存对象。Permanent：是指内存的永久保存区域，主要存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域. 它和和存放Instance的Heap区域不同,GC(Garbage Collection)

Tomcat内存溢出的原因　　在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存溢出是不一样的，当然处理方式也不一样。　　这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况：　　1.OutOfMemoryError： Java heap space　　2.OutOfMemoryError： PermGen space　　3.OutOfMemo

上次用weblogic 把 -XmxXXXX 设成2G，就启动不起来，设小点就起来了，当时很气，怎么2G都起不了，今天在看到了一篇解释，转过来了这 次一位老友提出了这个问题，记得当年一个java高手在blogjava提出后，被骂得半死。大家使用java -XmxXXXX -version版本得出了不同的结论。后来老友说大概是1800M左右，我当时反驳，“我设置过服务器8G内存，我使用两个tom

堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，如下图所示：从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，对老年代GC称为Major GC,而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor

摘要如果你的服务日志卡住了，请求不处理了，可能是JVM在垃圾回收，前后耗时一周左右，对线上服务的jvm进行了一次优化CMS的Full GC采用压缩式垃圾收集，在堆比较大的时候，如果full gc频繁，会导致停顿，并且调用方阻塞、超时、甚至雪崩的情况出现，所以降低full gc的发生频率和需要时间，非常有必要。目标减少full gc频率减少ygc和full