资源描述
JVM 的结构从功能上分，Java虚拟机主要由六个部分组成，可以分成三类：第一类：JVM API：就是我们最常用的Java API,它是开发人员和Java交互的入口，它主要是JAVA_HOME/jre/lib下的运行时类库rt.jar和编译相关的tools.jar第二类： JVM 内部组件类装载器(ClassLoader)：将Byte Array的.class文件装载、链接和初始化。内存管理(Memory Managent)：为对象分配内存，以及释放内存。后者就是垃圾回收Garbage Collector(GC)0由于JVM最复杂的、最影响性能的就是GC，所以内存管理一般就指垃圾回 收。诊断接口(Diagostics Interface)：这主要体现在JVMTI(jdk1.4下的JVMPI和JVMDI),它主要用 来诊断程序的问题和性能，一般提供给工具厂商实现。如eclispe IDE下的debug功能,Jprofiler 性能调优工具。类解释器(Interpreter)：解释装载进虚拟机的class对象，包括JIT等特性相关。第三类：平台相关接口(Platform Interface)：主要为了跨操作系统平台重用JVM代码，不过， 它和我们开发人员关系不大。在以上六个组件中，我们开发人员最关心的是ClassLoader和GC，用Java做系统框架、容器 和它们密切相关。 做业务系统时一些基础代码 也和它们打交道， 譬如最常用的 Class.forName(),Thread.currentThread.getContextClassLoader(。我们仔细想想，为什么是上 面两个问题？因为，它和我们class的整个生命周期最为相关：怎么将一个class和相关class 加载进来， class 实例什么时候创建，什么时候 被销毁？ 所以，下面的部分我们要专门讨论这些问题。在JVM中有两种垃圾方式，一种叫做Minor(次收集)，另一种叫做Major (主收集)。其中 Minor在Young Generation的空间被 对象全部占用后执行，主要是对Young Generation中的 对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集 经常发生，并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵的 垃圾收集方式，因为在Major要对 整个Heap size进行垃圾收集，这会使得应用停顿的时间变 得较长。java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx 256m SwingSet2.jar采用-XX:+UseConcMarkSweepGC选项在Heap Size比较大而且Major收集时间较长的情况下 使用更合适堆（Heap）和非堆（Non-heap）内存按照官方的说法：“Java虚拟机具有一个堆，堆是运行时数据区域，所有类实 例和数组的内存均从此处分配。堆是在Java虚拟机启动时创建的。”“在JVM 中堆之外的内存称为非堆内存（Non-heap memory）”。可以看出JVM主要管理两 种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发 人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化 所需的内存（如JIT编译后的代码缓存）、每个类结构（如运行时常数池、字段和 方法数据）以及方法和构造方法 的代码都在非堆内存中。 堆内存分配JVM初始分配的内存由-Xms指定，默认是物理内存的1/64； JVM最大分配的内 存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会 增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms 的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC后调整堆的 大小。 非堆内存分配JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由 XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。 JVM内存限制（最大值）首先JVM内存限制于实际的最大物理内存（废话！呵呵），假设物 理内存无限大 的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽 然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个 限制一般是 2GB-3GB（ 般来说 Windows 系统下为 1.5G-2G, Linux 系统下为 2G-3G）,而 64bit 以上的处理器就不会有限制了。jvm的调整没什么技巧，只有一些原则，要根据自己应用的特点来设定调优的目 标，这里收集了一些内容，权当记录Java heap （Xmx, Xms）和java进程的heap是两回事情java进程的heap包含：Java HeapPermanent GenerationThread stacksNative codeDirectly allocated memoryCode generationGarbage collectionTCP buffers因此我们在设置，jvm参数的时候得小心一点，一般我们会设置java heap和 perm gen,结合操作系统内存的大小和应用特点，选取一个合理的值。-Xms/-Xmxjavaheap 并不是越大越好，对他的一般优化原则是够用的情况下，尽可能的小， 因为太大的话会浪费内存，同时影响GC的效率-XX:NewSize/-XX:NewRatio一般设置为java heap的25%33%，太大或者太小都会影响GC，要根据应用 的特点，对象生命长短周期的比例来调整GC 相关调整的目标：咲 短生命周期的对象不要进入Old区衣短生命周期的对象在minor GC的时候干掉衣长生命周期的对象要放到Old区衣长生命周期的对象可以被Full GC清理掉，但是Full GC要调整到尽量少发 生 不管采用什么算法，GC总是会导致应用暂停的，这个时间长短从毫秒到秒之间 不等，因此会影响应用的相应时间，多长的停顿在接受范围内取决于应用的特征， 可以通过设置GC停顿的时间来调整（注意只是期望的时间，而不是绝对） -XX:MaxGCPauseMillis-XX:MaxGCMinorPauseMillis ，一般设置比较短的停顿 时间会导致相对较频繁的GC，根据应用的情况来调整Xms: java heap 初始化时的大小。默认情况是机器物理内存的 1/64。这个主要是根据应用启 动时消耗的资源决定，分配少了申请起来会降低启动速度，分配多了也浪费。Xmx:java heap的 最大值，默认是机器物理内存的1/4,最大也就到1G。这个值决定了 最多可用的Java Heap Memory，分配过少就会在应用需要大量内存作缓存或者零时对象时出 现00M的问题，如果分配过大，那么就会产生上文提到的第二类00M。所以如何配置还 是根据运行过程中的分析和计算来确定，如果不能确定还是采用默认的配置。Xmn:java heap新 生代的空间大小。在GC模型中，根据对象的生命周期的长短，产生 了内存分代的设计：青年代（内部也分成三部分，类似于整体划分的作用，可以通过配置来 设置 比例），老年代，持久代。每一代的管理和回收策略都不相同，最为活跃的就是青年代， 同时这部分的内存分配和管理效率也是最高。通常情况下，对于内存的申请 优先在新生代 中申请，当内存不够时会整理新生代，当整理以后还是不能满足申请的内存，就会向老年代 移动一些生命周期较长的对象。这种整理和移动会消耗资 源，同时降低系统运行响应能力， 因此如果青年代设置的过小，就会频繁的整理和移动，对性能造成影响。那是否把年青代设 置的越大越好，其实不然，年青代采用 的是复制搜集算法，这种算法必须停止所有应用程 序线程，服务器线程切换时间就会成为应用响应的瓶颈（当然永远不用收集那么就不存在这 个问题）。老年代采用 的是串行标记收集的方式，并发收集可以减少对于应用的影响。Xss :线程堆栈最大值。允许更多的虚拟内存空间地址被Java Heap使用。以下是sun公司的性能优化白皮书中提到的几个例子：1. 对于吞吐量的调优。机器配置：4G的内存，32个线程并发能力。java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20-Xmx3800m -Xms3800m配置了最大Java Heap来充分利用系统内存。-Xmn2g 创建足够大的青年代（可以并行被回收）充分利用系统内存，防止 将短期对象复制到老年代。-Xss128 减少默认最大的线程栈大小，提供更多的处理虚拟内存地址空间被 进程使用。-XX:+UseParallelGC 采用并行垃圾收集器对年青代的内存进行收集，提高 效率。-XX:ParallelGCThreads=20 减少垃圾收集线程，默认是和服务器可支持的 线程最大并发数相同，往往不需要配置到最大值。2. 尝试采用对老年代并行收集java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC-Xmx3550m -Xms3550m 内存分配被减小，因为 ParallelOldGC 会增加对于 Native Heap的需求，因此需要减小Java Heap来满足需求。-XX:+UseParallelOldGC 采用对于老年代并发收集的策略，可以提高收集效率。3. 提高吞吐量，减少应用停顿时间java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 选择了并发标记交换收集器，它可以并发执行收集操作，降低应用停止时间，同时它也是并 行处理模式，可以有效地利用多处理器的系统的多进程处理。-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31 表示在青年代中 Eden 和 Survivor比例，设置增加了 Survivor的大小，越大的survivor空间可以允许 短期对象尽量在年青代消亡。-XX:TargetSurvivorRatio=90 允许90%的空间被占用，超过默认的50%，提高对 于 survivor 的使用率。基本概念：PermGen space：全称是Permanent Generation space。就是说是永久保存的区域，用于存放Class和Meta 信息，Class在被Load的时候被放入该区域Heap space：存放 Instance GC（Garbage Collection）应该不会对 PermGen space 进行清理 所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误Java Heap 分为 3 个区， Young， Old 和 Permanent。 Young 保存刚实例化的对象。当该区被填满时， GC 会将对象移到Old区。Permanent区则负责保存反射对象。1. Heap设定与垃圾回收Java Heap分为3个区，Young, Old和Permanent。Young保存刚 实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对 象，本文不讨论该区。JVM的Heap分配可以使用-X参数设定，-Xms初始 Heap 大小-Xmxjava heap 最大值-Xmnyoung generation 的 heap 大小JVM有2个GC线程。第一个线程负责回收 Heap 的 Young 区。第二个线程在Heap不足时，遍历Heap,将Young区升级为Older区oOlder区的大小等于-Xmx减去-Xmn, 不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC?有如下原因：程序内调用了 System.gc()或 Runtime.gc()。一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。Java 的 Heap 太小，一般默认的 Heap 值都很小。频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String。如果你发现每次GC 后, Heap的剩余空间会是总空间的50%,这表示你的Heap处于健康状态。许多Server 端的 Java 程序每次 GC 后最好能有 65%的剩余空间。建议Server端JVM最好将-Xms 和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。 一个GUI程序最好是每10到20秒间运行一次GC,每次在半秒之内完成。增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线 程将暂停，也就是GC期间，Java应用程序不做任何工作。Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务 分配内存，例如每个线程的 Stack 等。Stack 的设定每个线程都有他自己的 Stack。-Xss 每个线程的 Stack 大小Stack的大小限制着线程的数量。如果Stack过大就会导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存， 来减少 Swap 空间的使用。4种GC1、第一种为单线程GC,也是默认的GC。，该GC适用于单CPU机器。2、第二种为Throughput GC,是多线程的GC,适用于多CPU,使用大量线程的程序。第二种GC与第 一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC 参数启动该 GC。3、第三种为Concurrent Low Pause GC,类似于第一种，适用于多CPU,并要求缩短因GC造成程序停 滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动 该 GC。4、第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在 Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。JVM 参数配置1: heap sizea: -Xmx指定 jvm 的最大 heap 大小 , 如 :-Xmx=2gb: -Xms指定jvm的最小heap大小，如:-Xms=2g，高并发应用，建议和-Xmx 样，防止因为内存收缩/ 突然增大带来的性能影响。c: -Xmn指定 jvm 中 New Generation 的大小 , 如 :-Xmn256m。 这个参数很影响性能， 如果你的程序需要比 较多的临时内存，建议设置到512M,如果用的少，尽量降低这个数值，一般来说128/256足以使用 了。d: -XX:PermSize=指定 jvm 中 Perm Generation 的最小值 , 如 :-XX:PermSize=32m。 这个参数需要看你的实际情况，。 可以通过 jmap 命令看看到底需要多少。e: -XX:MaxPermSize=指定 Perm Generation 的最大值 , 如 :-XX:MaxPermSize=64mf: -Xss指定线程桟大小，如：-Xss128k,般来说，webx框架下的应用需要256K。如果你的程序有大规模的递归行为，请考虑设置到512K/1M。这个需要全面的测试才能知道。不过，256K已经很大了。这个 参数对性能的影响比较大的。g: -XX:NewRatio=指定 jvm 中 Old Generation heap size 与 New Generation 的比例 , 在使用 CMS GC 的情况下此参 数失效 , 如 :-XX:NewRatio=2h: -XX:SurvivorRatio=指 定 New Generation 中 Eden Space 与一个 Survivor Space 的 heap size 比例 ,-XX:SurvivorRatio=8, 那么在总共 New Generation 为 10m 的情况下 ,Eden Space 为 8mi: -XX:MinHeapFreeRatio=指定 jvm heap 在使用率小于 n 的情况下 ,heap 进行收缩 ,Xmx=Xms 的情况下无效 ,如 :-XX:MinHeapFreeRatio=30j: -XX:MaxHeapFreeRatio=指定 jvm heap 在使用率大于 n 的情况下 ,heap 进行扩张 ,Xmx=Xms 的情况下无效 , 如 :-XX:MaxHeapFreeRatio=70k: -XX:LargePageSizeInBytes=指定 Java heap 的分页页面大小 , 如 :-XX:LargePageSizeInBytes=128m2: garbage collectora: -XX:+UseParallelGC指 定在 New Generation 使用 parallel collector, 并行收集 , 暂停 app threads, 同时启动多个垃圾回收 thread, 不能和 CMS gc 一起使用 . 系统吨吐量优先 , 但是会有较长长时间的 app pause, 后台系统任 务可以使用此 gcb: -XX:ParallelGCThreads=指定 parallel collection 时启动的 thread 个数 , 默认是物理 processor 的个数 ,c: -XX:+UseParallelOldGC 指定在 Old Generation 使用 parallel collectord: -XX:+UseParNewGC指定在 New Generation 使用 parallel collector, 是 UseParallelGC 的 gc 的升级版本 , 有更好的性能 或者优点 , 可以和 CMS gc 一起使用e: -XX:+CMSParallelRemarkEnabled在使用 UseParNewGC 的情况下 , 尽量减少 mark 的时间f: -XX:+UseConcMarkSweepGC指 定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread). app pause 时间较短 , 适合交互性强的系统 , 如 web serverg: -XX:+UseCMSCompactAtFullCollection在使用 concurrent gc 的情况下 , 防止 memory fragmention, 对 live object 进行整理 , 使 memory 碎 片减少h: -XX:CMSInitiatingOccupancyFraction=指示在 old generation 在使用了 n% 的比例后 , 启动 concurrent collector, 默认值是 68, 如 :-XX:CMSInitiatingOccupancyFraction=70i: -XX:+UseCMSInitiatingOccupancyOnly 指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集3:others a: -XX:MaxTenuringThreshold=指 定一个 object 在经历了 n 次 young gc 后转移到 old generation 区 , 在 linux64 的 java6 下默认 值是 15, 此参数对于 throughput collector 无效 , 如 :-XX:MaxTenuringThreshold=31b: -XX:+DisableExplicitGC禁止 java 程序中的 full gc, 如 System.gc() 的调用. 最好加上么， 防止程序在代码里误用了。对性能造 成冲击。c: -XX:+UseFastAccessorMethodsget,set 方法转成本地代码d: -XX:+PrintGCDetails打应垃圾收集的情况如 :GC 15610.466: ParNew: 229689K-20221K(235968K), 0.0194460 secs1159829K-953935K(2070976K), 0.0196420 secse: -XX:+PrintGCTimeStamps打应垃圾收集的时间情况 , 如 :Times: user=0.09 sys=0.00, real=0.02 secsf: -XX:+PrintGCApplicationStoppedTime打应垃圾收集时 , 系统的停顿时间 , 如 :Total time for which application threads were stopped: 0.0225920 secondsJVM 内存的调优1. Heap 设定与垃圾回收 Java Heap 分为 3 个区，Young, Old 和 Permanent。Young 保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent 区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可以使用-X参数设 定，-Xms初始 Heap 大小-Xmxjava heap 最大值-Xmnyoung generation 的heap 大小JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap 不足时，遍历Heap，将Young区升级为Older区。Older区的大小等于-Xmx减 去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性Tomcat 配置问题分析：由于TOMCAT内存溢出而引发的问题，主要原因是JVM的虚拟内存默认为 128M，当超过这个值时就把先前占用的内存释放，而导致好象TCP/IP丢包的假 象，出现HTTP500的错误。解决方法主要是加大TOMCAT可利用内存，并在程序 当中加大内存使用。解决方法：Linux 下修改 JVM 内存大小:要添加在 tomcat 的 bin 下 catalina.sh 里，位置 cygwin=false 前 。注意引 号要带上,红色的为新添加的.# OS specific support. $var _must_ be set to either true or false. JAVA_OPTS=-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m cygwin=false此时执行ps -ef|grep tomcat可以看到tomcat的参数中添加了上面的参数 也可以在/etc/profile文件中添加export JAVA_OPTS=-Xms256m -Xmx512m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m然后 source /etc/profile windows 下修改 JVM 内存大小:情况一:解压版本的 Tomcat, 要通过 startup.bat 启动 tomcat 才能加载配置要添加在 tomcat 的 bin 下 catalina.bat 里rem Guess CATALINA_HOME if not definedset CURRENT_DIR=%cd%后面添加，红色的为新添加的.set JAVA_OPTS=-Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m-XX:MaxPermSize=256m -Djava.awt.headless=true安装版的 Tomcat 下没有 catalina.batwindows服务执行的是bintomcat.exe.他读取注册表中的值，而不是 catalina.bat 的设置.修改注册表 HKEY_LOCAL_MACHINESOFTWAREApache SoftwareFoundationTomcat Service ManagerTomcat5ParametersJavaOptions 原值为-Dcatalina.home=C:ApacheGroupTomcat 5.0 -Djava.endorsed.dirs=C:ApacheGroupTomcat 5.0commonendorsed-Xrs加入 -Xms300m -Xmx350m重起 tomcat 服务， 设置生效三.WebLogic 配置：由于WebLogic的配置问题，我们的测试出现了失败情况。原因是为WebLogic 分配的内存太少了。通过修改 commombincommEnv.cmd 文件来增加内存分配。修改的部分如下：:beaif %PRODUCTION_MODE% = true goto bea_prod_modeset JAVA_VM=-jrockitset MEM_ARGS=-Xms768m -Xmx1024mset JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:nonegoto continue:bea_prod_modeset JAVA_VM=-jrockitset MEM_ARGS二-Xms768m -Xmxl024m/原来是 128M256M，太小了，数据太大goto continue结果修改后，没有效果。还是有失败的情况。发现，原来，在：bea下面还有一段配置信息如下:sun if %PRODUCTION_MODE% = true goto sun_prod_modeset JAVA_VM=-clientset MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256mset JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:nonegoto continue:sun_prod_modeset JAVA_VM=-serverset MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256mgoto continue将这里的内存分配修改后见效。原因是，上面对第一段代码是为 bea 自己的 JVM 设置的，下面的是为 Sun 的设置 的。而WebLogic默认的是Sun的，所以出了毛病。在JDK的选择上，weblogic 有两种JDK供选择，一种是Sun的JDK，另外一种是Bea的jrockit。按照bea 的网站的说明， sunjdk 提供更好的兼容性，而使用 jrockit 可以提供更好的性 能。作为weblogic集群我全部采用jrockit作为JDK环境，以达到更高的性能。在默认启动情况下， jrockit 启动时为其窗口配置的内存大小比较小。注意 weblogic的启动内存配置-Xms32m -Xmx256m，通过修改commEnv.sh可以修改这 个参数，Xms表示启动开始分配的内存，Xmx表示最大能分配的内存，这里我们 根据应用情况调整为-Xms1536m -Xmx1536m，这点需要根据自身测试情况和系统 配置进行调整，经过周一晚的调试，我们目前应用比较合理的窗口内存大小为 1536M (2GX 75%)，通过top可以观察到测试中的内存反应，最合理的应该是 恰好把物理内存用完。也可以在、/etc/profile中设置：USER_MEM_ARGS=-server -Xms2048M -Xmx2048M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8查到 setDomianEnv.sh 里面有一段# IF USER_MEM_ARGS the environment variable is set, use it to override ALL MEM_ARGS values if $USER_MEM_ARGS != ; thenMEM_ARGS=$USER_MEM_ARGS export MEM_ARGSfi意思就是设置了这个参数就会覆盖所有MEM_ARGS初始值吧。jstat 工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及 加载类的数量。使用时，需加上查看进程的进程id,和所选参数。以下详细介 绍各个参数的意义。jstat -class pid:显示加载class的数量，及所占空间等信息。jstat -compiler pid:显示VM实时编译的数量等信息。jstat -gc pid:可以显示gc的信息，查看gc的次数，及时间。其中最后五项， 分别是 younggc 的次数， younggc 的时间， fullgc 的次数， fullgc 的时间， gc 的总时间。jstat -gccapacity:可以显示，VM内存中三代(young,old,perm)对象的使用 和占用大小，女如PGCMN显示的是最小perm的内存使 用量，PGCMX显示的是perm 的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存 占用量。其他的可以根据这个类推，OC是old内纯的占用量。jstat -gcnew pid:new 对象的信息。jstat -gcnewcapacity pid:new 对象的信息及其占用量。jstat -gcold pid:old 对象的信息。jstat -gcoldcapacity pid:old 对象的信息及其占用量。jstat -gcpermcapacity pid: perm对象的信息及其占用量。jstat -util pid:统计gc信息统计。jstat -printcompilation pid:当前 VM 执行的信息。除了以上一个参数外，还可以同时加上 两个数字，如：jstat -printcompilation 3024 250 6是每250毫秒打印一次，一共打印6次，还可以加上-h3每三行显示 一下标题。jmap是一个可以输出所有内存中对象的工具，甚至可以将VM中的heap，以二 进制输出成文本。使用方法jmap -histo pid。如果连用SHELL jmap -histo pida.log可以将其保存到文本中去，在一段时间后，使用文本对比工具，可以 对比出 GC 回收了哪些对象。jmap -dump:format二b,f ile=String 3024可以将 3024 进程的内存 heap 输出出来到 String 文件里。jinfo:的用处比较简单，就是能输出并修改运行时的java进程的运行参数。用 法是jinfo -opt pid女如查看2788的MaxPerm大小可以用 jinfo -flag MaxPermSize 2788。jps :查看当前运行的jvm进程号jstack:打印当前某个jvm的详细的线程堆栈信息jstat -gc S0C S1CS0US1UEC EU OC OU PC PUYGC YGCT FGCCurrent survivor Current survivor Survivor space 0 Survivor space 1space 0 capacity space 1 capacity utilization (KB). utilization (KB).Current eden space capacity (KB). Eden space utilization (KB).Current old space capacity (KB). Old space utilization (KB).Current permanent space capacity Permanent space utilization (KB).Number of young generation GC Events.Young generation garbage collectionNumber of full GC events.FGCT Full garbage collection time. GCT Total garbage collection time.当前 survivor0 的容量 当前 survivor1 的容量 survivor0 的使用 survivor1 的使用当前eden的容量 eden 的使用 当前old的容量old 的使用 当前perm的容量 perm 的使用 young gc 的次数 young gc 的总时间(KB).(KB).(KB).time.full gc 的次数full gc 的总时间所有gc的总时间
展开阅读全文