为 i系列上的Java和Websphere应用进行垃圾回收(Garbage Collection)调节
你必须了解的java内存管理机制（四）-垃圾回收
你必须了解的java内存管理机制（四）-垃圾回收本⽂在个⼈技术博客不同步发布，详情可亦可扫描屏幕右侧⼆维码关注个⼈公众号，公众号内有个⼈联系⽅式，等你来撩...相关链接（注：⽂章讲解JVM以Hotspot虚拟机为例，jdk版本为1.8）1、2、3、4、前⾔ 在前⾯三篇⽂章中，对JVM的内存布局、内存分配、垃圾标记做了较多的介绍，垃圾都已经标记出来了，那剩下的就是如何⾼效的去回收啦！这篇⽂章将重点介绍如何回收旧⼿机、电脑、彩电、冰箱~啊呸(⊙o⊙)…将重点介绍⼏种垃圾回收算法、HotSpot中常⽤的垃圾收集器的主要特点和应⽤场景。
同时，这篇⽂章也是这个系列中的最后⼀篇⽂章啦！正⽂ 上⼀篇⽂章中，我们详细介绍了两种标记算法，并且对可达性分析算法做了较多的介绍。
我们也知道了HotSpot在具体实现中怎么利⽤OopMap+RememberedSet的技术做到“准确式GC”。
不管使⽤什么优化的技术，⽬标都是准确⾼效的标记回收对象！那么，为了⾼效的回收垃圾，虚拟机⼜经历了哪些技术及算法的演变和优化呢？（注：G1收集器及回收算法本⽂不涉及，因为我觉得后⾯可以单独写⼀篇⽂章来谈！）回收算法 在这⾥，我们会先介绍⼏种常⽤的回收算法，然后了解在JVM中式如何对这⼏种算法进⾏选择和优化的。
标记-清除 "标记-清除"算法分为两个阶段，“标记”和“清除”。
标记还是那个标记，在上⼀篇⽂章中已经做了较多的介绍了，JVM在执⾏完标记动作后，还在"即将回收"集合的对象将被统⼀回收。
执⾏过程如下图： 优点： 1、基于最基础的可达性分析算法，它是最基础的收集算法。
2、后续的收集算法都是基于这种思路并对其不⾜进⾏改进⽽得到的。
缺点： 1、执⾏效率不⾼。
2、由上图能看到这种回收算法会产⽣⼤量不连续内存碎⽚，如果这时候需要创建⼀个⼤对象，则⽆法进⾏分配。
复制算法 “复制”算法将内存按容量划分为⼤⼩相等的两块，每次使⽤其中的⼀块。
JAVA的内存回收机制(快速入门版)
JAVA的内存回收机制（快速入门版）Java的内存回收机制是通过垃圾回收（Garbage Collection）来实现的。
垃圾回收是一种自动化的内存管理机制，它可以在程序运行时自动分配和释放内存。
Java的垃圾回收机制允许开发人员不用手动释放内存，从而减轻了编程的负担和错误。
Java的内存回收机制是基于“垃圾”的概念。
垃圾是指在程序中已经不再被使用的对象。
当一个对象不再被引用时，它就成为了垃圾。
垃圾回收器会定期扫描程序的堆内存，识别和清除垃圾对象，以便为新的对象腾出内存空间。
Java的内存回收机制是基于引用计数和可达性分析两种策略的组合。
引用计数是一种简单的方法，它通过在对象上添加一个引用计数器来跟踪对象被引用的次数。
当引用计数为0时，对象就成为垃圾。
可达性分析是一种更高级的方法，它通过从根节点（如变量、静态变量等）开始，递归地遍历对象图，标记所有可达的对象，未标记的对象就是垃圾。
Java的垃圾回收器包括几种不同的实现，如串行回收器、并行回收器和并发回收器等。
这些回收器采用不同的算法和策略来进行内存回收。
例如，串行回收器在垃圾回收过程中会暂停程序的执行，而并行回收器则会同时利用多个处理器来提高回收效率。
并发回收器则允许程序在垃圾回收过程中继续执行。
Java的内存回收机制还包括一些高级的特性，如分代回收和自适应调整。
分代回收是一种基于对象存活时间的策略，它将堆内存划分为不同的代（Generation），并根据对象的特性来选择合适的回收算法。
自适应调整是一种动态调整垃圾回收参数的机制，它可以根据程序的运行情况来调整回收策略，以达到更好的性能。
总的来说，Java的内存回收机制是一种自动化的内存管理机制，它通过识别和清除垃圾对象来释放内存空间。
Java提供了多种不同的垃圾回收器和高级特性，可以根据不同的应用场景来选择合适的策略。
掌握Java的内存回收机制可以帮助开发人员编写高效、可靠的程序。
图解JAVA垃圾回收机制（转）
图解JAVA垃圾回收机制（转）摘要： Java技术体系中所提倡的⾃动内存管理最终可以归结为⾃动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存，⽽且这两个问题针对的内存区域就是Java内存模型中的堆区。
关于对象分配内存问题，笔者的博⽂已经阐述了如何划分可⽤空间及其涉及到的线程安全问题，本⽂将结合垃圾回收策略进⼀步给出内存分配规则。
垃圾回收机制的引⼊可以有效的防⽌内存泄露、保证内存的有效使⽤，也⼤⼤解放了Java程序员的双⼿，使得他们在编写程序的时候不再需要考虑内存管理。
本⽂着重介绍了判断⼀个对象是否可以被回收的两种经典算法，并详述了四种典型的垃圾回收算法的基本思想及其直接应⽤——垃圾收集器，最后结合内存回收策略介绍了内存分配规则。
友情提⽰： 为了更好地了解Java的垃圾回收机制，笔者建议读者先要对JVM内存模型有⼀个整体的了解和把握。
鉴于笔者在博⽂中已经深⼊介绍了JVM内存模型，此不赘述。
本⽂内容是基于 JDK 1.6 的，不同版本虚拟机之间也许会有些许差异，但不影响我们对JVM垃圾回收机制的整体把握和了解。
⼀、垃圾回收机制的意义 在笔者的上⼀篇博⽂中提到，JVM 内存模型⼀共包括三个部分：堆 ( Java代码可及的 Java堆和 JVM⾃⾝使⽤的⽅法区)、栈 ( 服务Java⽅法的虚拟机栈和服务Native⽅法的本地⽅法栈 ) 和保证程序在多线程环境下能够连续执⾏的程序计数器。
特别地，我们当时就提到Java堆是进⾏垃圾回收的主要区域，故其也被称为GC堆；⽽⽅法区也有⼀个不太严谨的表述，就是永久代。
总的来说，堆 (包括Java堆和⽅法区)是垃圾回收的主要对象，特别是Java堆。
实际上，Java技术体系中所提倡的⾃动内存管理最终可以归结为⾃动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存，⽽且这两个问题针对的内存区域就是Java内存模型中的堆区。
关于对象分配内存问题，笔者的博⽂已经阐述了如何划分可⽤空间及其涉及到的线程安全问题，本⽂将结合垃圾回收策略进⼀步给出内存分配规则。
简单介绍Java垃圾回收机制
简单介绍Java垃圾回收机制Java的内存分配与回收全部由JVM垃圾回收进程⾃动完成。
与C语⾔不同，Java开发者不需要⾃⼰编写代码实现垃圾回收。
这是Java深受⼤家欢迎的众多特性之⼀，能够帮助程序员更好地编写Java程序。
这篇教程是系列第⼀部分。
⾸先会解释基本的术语，⽐如JDK、JVM、JRE和HotSpotVM。
接着会介绍JVM结构和Java堆内存结构。
理解这些基础对于理解后⾯的垃圾回收知识很重要。
Java关键术语JavaAPI：⼀系列帮助开发者创建Java应⽤程序的封装好的库。
Java开发⼯具包（JDK）：⼀系列⼯具帮助开发者创建Java应⽤程序。
JDK包含⼯具编译、运⾏、打包、分发和监视Java应⽤程序。
Java虚拟机（JVM）：JVM是⼀个抽象的计算机结构。
Java程序根据JVM的特性编写。
JVM针对特定于操作系统并且可以将Java指令翻译成底层系统的指令并执⾏。
JVM确保了Java的平台⽆关性。
Java运⾏环境（JRE）：JRE包含JVM实现和JavaAPI。
JavaHotSpot虚拟机每种JVM实现可能采⽤不同的⽅法实现垃圾回收机制。
在收购SUN之前，Oracle使⽤的是JRockitJVM，收购之后使⽤HotSpotJVM。
⽬前Oracle拥有两种JVM实现并且⼀段时间后两个JVM实现会合⼆为⼀。
HotSpotJVM是⽬前OracleSE平台标准核⼼组件的⼀部分。
在这篇垃圾回收教程中，我们将会了解基于HotSpot虚拟机的垃圾回收原则。
JVM体系结构下⾯图⽚总结了JVM的关键组件。
在JVM体系结构中，与垃圾回收相关的两个主要组件是堆内存和垃圾回收器。
堆内存是内存数据区，⽤来保存运⾏时的对象实例。
垃圾回收器也会在这⾥操作。
现在我们知道这些组件是如何在框架中⼯作的。
Java堆内存我们有必要了解堆内存在JVM内存模型的⾓⾊。
在运⾏时，Java的实例被存放在堆内存区域。
当⼀个对象不再被引⽤时，满⾜条件就会从堆内存移除。
java gc讲解
Java中的垃圾回收（Garbage Collection，GC）是自动内存管理的一种机制。
Java程序员不需要显式地进行内存管理，因为Java虚拟机（JVM）会自动管理内存。
垃圾回收器（GC器）会定期检查堆内存中不再使用的对象，并将其释放，以便其他对象可以使用这些空间。
Java的GC机制基于以下几个原则：
1.对象只有在没有被引用时才会被回收。
垃圾回收器会定期扫描堆内存，找出不再被
引用的对象，并将它们从堆内存中删除。
2.Java虚拟机中的堆内存被分成若干个不同的代。
新创建的对象会被分配到年轻代
（Young Generation），经过多次垃圾回收后，如果仍然存活，则会被移动到年老代（Old Generation）。
年老代中存活时间较长的对象可能会被移动到持久代（Permanent Generation），其中主要存放JVM使用的类信息、方法信息等。
3.垃圾回收器的工作是尽可能快地释放内存，同时保证程序的性能。
为了实现这一目
标，Java中使用了不同类型的垃圾回收器，例如串行回收器、并发标记-清除回收器、并行回收器、G1垃圾回收器等。
每个垃圾回收器都有其优缺点，应根据应用程序的需求进行选择。
Java中的垃圾回收机制可以大大简化程序员的工作，并提高代码的可靠性和稳定性。
但是，Java垃圾回收也会带来一些额外的开销，例如GC停顿时间较长、内存占用较高等问题。
因此，程序员需要了解Java垃圾回收机制的工作原理，并针对具体情况进行调整和优化，以提高程序的性能和可靠性。
深入理解Java垃圾回收机制
深入理解Java垃圾回收机制Java作为一门面向对象的编程语言，其垃圾回收机制是其核心功能之一。
Java垃圾回收机制以其高效、可靠的特性，为程序员们带来了很大的便利。
但对于初学者和一些开发者，Java垃圾回收机制还是比较神秘的。
本文将从深入理解Java垃圾回收机制方面进行探讨。
Java垃圾回收机制的概念对于Java垃圾回收机制，我们首先需要了解的是垃圾回收机制的概念。
简单来说，垃圾回收机制就是在程序运行时，自动清除不再使用的对象，并回收其占用的内存空间。
这样做既能够让程序节省内存空间，也可以避免内存泄漏等问题的发生。
Java垃圾回收机制的执行方式Java垃圾回收机制的执行方式可以分为两种，即标记-清除法和复制-清除法。
1. 标记-清除法标记-清除法是指，当垃圾回收机制开始工作时，它会标记所有正在使用的对象和被使用的对象之间的关系。
然后，它会扫描程序中所有的对象，并将被使用的对象打上“标记”，将不再使用的对象打上“不可达标记”。
最后，垃圾回收机制回收那些被打上“不可达标记”的对象，并释放其占用的内存空间。
2. 复制-清除法复制-清除法是指，当垃圾回收机制开始工作时，它会将整个可用内存区域分为两个相等的部分，分别称为“From”空间和“To”空间。
当程序对象在进行分配内存时，垃圾回收机制会将对象分配在From空间中。
当From空间被占满时，垃圾回收机制会暂停程序运行，并将所有存活的对象从From空间复制到To空间，然后将From空间进行清除，最后将To空间作为新的From空间。
这种方式既能够让内存得到有效的利用，也可以确保程序的稳定运行。
Java垃圾回收机制的内存分区Java垃圾回收机制的内存分区可以分为程序计数器、虚拟机栈、方法区、堆（Heap）四个部分。
其中，程序计数器保存下一个要执行的指令的地址；虚拟机栈保存线程方法的信息；方法区保存类、方法及常量池的信息；堆是程序运行时所使用的内存区域。
Java垃圾回收机制的垃圾收集器Java垃圾回收机制的垃圾收集器是Java虚拟机中专门负责回收垃圾对象的模块，其具体实现方式取决于Java虚拟机的版本和厂商。
java对象的回收方式,回收算法
java对象的回收方式,回收算法Java中的内存管理是自动化的，它由垃圾收集器（Garbage Collector）完成。
在应用程序执行期间，如果一个对象不再被引用，那么它就可以被垃圾回收器回收掉。
1. 垃圾收集器垃圾收集器的作用是标记和回收无用对象。
Java平台的所有实现都附带了一个或多个垃圾收集器。
2. 垃圾回收算法垃圾回收算法的选择取决于实现。
大多数JVM实现使用标记-清除（Mark-Sweep）算法。
标记-清除算法：标记-清除算法是最简单的垃圾回收算法之一。
该算法分为两个步骤：标记 - 垃圾回收器在堆中从根节点开始遍历所有对象，标记所有可到达的对象。
这个算法有几个缺点，首先它会产生大量的内存碎片，这可能会导致分配大的对象失败。
其次，该算法在执行回收操作时会暂停应用程序的执行，这会导致应用程序的响应时间受到影响。
复制算法：复制算法是为了解决标记-清除算法的问题而出现的。
该算法首先将堆分为两个区域，一半为使用区，另一半为空闲区。
当使用区的对象需要被回收时，垃圾回收器会将存活的对象从使用区复制到空闲区中。
这种方式会带来额外的开销，但由于对象被连续地存储在空闲区，因此不再有内存碎片的问题。
标记-压缩算法是标记-清除算法的改进，该算法可以减少内存碎片。
该算法在标记-清除算法的基础上增加了一个步骤，即在清除之后压缩未使用的空间，并将前后相邻的未使用空间合并。
这种方式可以使得内存的使用更加紧凑。
它也是一种阻塞式算法。
3. 内存管理Java的垃圾收集器是自动管理内存。
Java堆主要分为两个区域：年轻代和老年代。
年轻代：年轻代是指新创建的对象所存储的区域。
年轻代由一个Eden空间和两个Survivor空间组成。
当一个对象被创建时，它都会在Eden空间内部分配空间。
当Eden空间满了之后，Java垃圾收集器会将存活的对象复制到Survivor空间中，并将Eden空间回收。
这个过程称为Minor GC。
老年代是指对象已经存活一段时间的区域。
javagc的工作机制
javagc的工作机制Java的垃圾回收（Garbage Collection，简称GC）是Java语言中的一种自动内存管理机制，它主要负责回收程序中不再使用的对象，释放它们所占用的内存资源，以提高系统的性能和效率。
Java的GC工作机制可以理解为一个自动的垃圾收集器，它负责监控程序中的内存使用情况，并在必要时回收不再使用的对象。
Java 的垃圾回收是基于可达性分析算法的，即通过判断对象是否可达来确定其是否需要被回收。
在Java中，每当创建一个新的对象时，Java虚拟机（JVM）会为其分配一块内存空间。
当这个对象不再被程序引用时，就成为了垃圾，垃圾回收机制会在合适的时机将其回收并释放内存空间。
为了确定一个对象是否可达，GC会从一组称为“根”的对象开始遍历，然后根据引用关系遍历整个对象图，标记所有可达的对象。
未被标记的对象即为不可达对象，将会被回收。
垃圾回收的触发时机是由Java虚拟机决定的，一般情况下，当系统的内存占用达到一定阈值时，垃圾回收机制就会被触发。
在进行垃圾回收时，Java虚拟机会暂停程序的执行，然后扫描整个堆内存，标记并回收不可达对象。
这个过程被称为“Stop-The-World”，会导致一段时间的系统停顿，对于实时性要求较高的应用可能会产生影响。
为了避免过多的垃圾回收，Java提供了不同的垃圾回收器，可以根据应用的需求选择合适的回收器。
常见的垃圾回收算法有标记-清除算法、复制算法、标记-整理算法等。
不同的垃圾回收器有不同的特点和适用场景，比如Serial收集器适用于小型应用，Parallel收集器适用于多核心处理器，CMS收集器适用于低延迟应用等。
除了选择合适的垃圾回收器，开发人员还可以通过一些手段来优化垃圾回收的性能。
比如，可以通过减少对象的创建和销毁次数，避免产生过多的临时对象；可以通过合理设置堆内存大小和垃圾回收的阈值，以减少垃圾回收的频率和停顿时间；还可以通过手动调用System.gc()方法来建议垃圾回收机制执行回收操作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
同时修改"refresh rate",把缺省的10秒刷新时间改成1秒(从"Option"菜单里选择"Set Refresh Rate..."). 但因为它会加重系统负荷,所以请在不需要 时修改回来. 选中左边的"JVM Runtime",并选择右边的"View Chart" tab,可见图:
"Used memory" -- 当前堆(heap)大小 "Total memory" -- 分配给JVM的内存总量 "Free memory" – Total 和 Used 的差值,如果它接近"0",代表需要增加分配给JVM的内存总量 所以,此图很好的标识了堆大小随时间的变化.总的说来,堆初始增长;当GC运行,堆大小会减少;直到GC运行结束,堆会再增加.根据此图,可以监控是否环 境的变化需要对GC再做修改.比如,如果"Used memory"急速增加,或者GC运行很频繁,就需要增加"initial heap size"; 如果"total memory"在一段时间 内持续增加,说明你的应用可能出现了"object leak"现象,它最终会造成应用"OutOfMemoryExceptions".
在i系列上,有两个参数会影响GC的性能: (1) Initial Heap Size -- 在Java命令行用"-Xms (or -ms)"来进行设定,比如"java -Xms256m MyClass"就代表了Java运行时初始分配的堆(内存)大小是 256MB.此参数也可以通过WAS主控台用图形化界面进入"JVM Settings"来填写参数,如下图所示. (2) Maximum Heap Size -- 在Java命令行用"-Xmx (or -mx)"来进行设定,但一般建议不要修改缺省值 *NOMAX.此参数也可以通过WAS主控台用图形化界面 进入"JVM Settings"来填写参数,如下图所
小节: 还是强调,最好的优化GC的方法就是不断监控系统运行情况和性能数据从而不断调整"initial heap size"来测试.一般来说,设置"initial heap size"使得 GC间隔在10-15秒是比较合适的. 如果是单路或双路处理器,建议从设置"initial heap size"值为32MB/64MB开始监控测试; 如果是4路或8路处理器,建议从设置"initial heap size"为 256MB/512MB开始监控测试; 如果是12路或24路处理器,建议从设置"initial heap size"为1GB开始监控测试. 如果系统内存不足够大,最好保持GC的"initial heap size"值较低,增加GC运行频率,减小堆值,从而确保整个堆内容都在内存里,而不用在硬盘和内存间调 用.用WRKSYSSTS命令或系统的收集服务查看"non-database paging/faulting rates".在非"warm-up"阶段,如果"non-database paging rates"持续超过"10 faults per second",说明"initial heap size"太大了.当然,在混合应用使用的内存池里,"non-database paging rates"过高不一定是JVM的GC设置引起的. 所以最好隔离JVM应用在单独的内存池里运行,这样监控到的指标才更准确. 如果内存过于吃紧,可以设置"maximum heap size"值.缺省它是*NOMAX,所以GC何时运行就只和"initial heap size"有关.但如果修改"maximum heap size" 成为一个真实值,GC在它达到时也会运行.但不同于平常,当"maximum heap size"达到并激活GC,所有应用的线程会被挂起,直到GC运行完成.从而,应用会有 不可预测的暂停行为(pause times).所以,"maximum heap size"的设置要作为对付异常堆增长而引发的内存溢出的最后一道屏障. 除了调节GC,也可以调节应用,使得它少产生对象.这是一个所有平台上的共同问题,在此不再详细讨论. 所以说,在OS/400里,JVM的性能如果涉及到对GC的调节,通常只有一个参数可改 -- "initial heap size" (其它平台上可能有50到60个参数要调); 而有无 数工具来辅助监控和分析GC性能.在应用不做任何改动的情况下,当应用达到平稳运行状态,几分钟的性能监控和正确的参数修改,就可以极大的提高 Java/WAS应用的性能.
参考资料: /iseries/perfmgmt/ /servers/eserver/iseries/perfmgmt/webjtune.html /was400/51/english/info/rzaiz/51/perf/prftunehot.htm /servers/enable/site/education/ibp/perf_analysis/index.htm
示.
注意,i系列上对"initial heap size"的定义是很独特的.在非OS/400平台上,"initial heap size"只是代表初始分配给JVM的内存值,GC何时运行是JVM根据 何时有空闲等条件来决定的;当初始分配的内存不够用,系统会为JVM增加内存分配,直到达到"maximum heap size",所以"maximum heap size"对GC就很有影 响,或者由它触发了一次GC,或者报"Out of Memory"的错误. 但在i系列上基本不需要设置"maximum heap size"(缺省值*NOMAX).因为在i系列里,垃圾回收的执行是基于"initial heap size"参数.它实际上是一个阙值, 来触发垃圾回收.请注意,它不是绝对heap size,而是上次GC到这次GC之间的堆的增长大小.所以,当JVM对内存的占用首次达到这个值, GC会运行,会有部分 内存被释放.在这次剩余内存空间基础上,当有和"initial heap size"标识大小的内存空间又被JVM占用,GC才会再一次自动运行."initial heap size"设得 越大,GC运行频率越低,但在两次GC执行其间JVM占用的内存资源越多,下次GC运行时间也会加长.所以通过调节"initial heap size"的值就可以试图找到一 个GC运行频率和heap size大小的最优平衡点.
(6)i系列上的"Job Watcher tool"工具也可以用来监控 JVM heap size,信息抓取频率高达每秒10次.Job Watcher 可用在单独的Java/WAS应用上. 详细信息请参阅 /i_dir/idoctor.nsf/jw.html .
(2)Verbose GC 如果希望收集GC运行时的更多数据,可以使用"-verbose GC",抓取出信息放入"System.out"里.这些信息包括: 当前堆大小(heap size),被回收的对象的 数量和大小,堆中所存在的对象数量,回收运行所花费的时间等信息. 激活"Verbose GC"的方法很简单,只需在Java命令行添加参数"-verbosegc"即可, 或者在WAS主控台用图形化界面点中参数"Verbose Mode Garbage Collection",如 检查GC是否运行高效的最简单方法就是查看CPU分给GC执行的时间百分比.可以使用PEX(Performance Explorer),收集 trace profile 数据,用*PROGRAM 选项生成报告.在报告的最后一段将有系统分给各个程序运行的CPU时间百分比,如图:
得到的结果格式如下(在"System.out"里):
重要参数解释 -GC 4 : 代表是自JVM启动后的第四次GC回收运行. Live objects : 当前在JVM里处于活动状态的对象数量 Collected objects : 在这次GC里被回收的对象数量 Collected(KB) : 在这次GC里被回收的对象总大小 Current heap(KB): 当前堆大小 Current threshold(KB): 当前阙值,也就是"initial heap size"值 Collect (milliseconds): 这次GC运行时间 Current cycle allocation(KB): 这次GC开始运行到目前为止这段时间内分配的内存量(因为Java应用在GC其间是不用停止的) Previous cycle allocation(KB): 上一次GC开始运行和这次GC开始运行这段时间内增加的内存量,其实它就应该和"initial heap size"大致一样 如上图所示,第四次GC花费了4秒多才运行完成.因为Java应用在GC其间是不停的,所以在这4秒其间,应用又占用了超过200MB内存,是阙值的40%.通过分 析,可以猜想本次GC和下次GC的时间间隔将大约是10秒.本次GC回收了大约5百万个对象,留下了大约2百50万个对象.所以,通过使用"verbose GC"就可以 了解应用是如何使用heap的. 通常,每次GC执行的时间越短越好,比如1-2秒;如果是WAS应用,5-10秒也是可以接受的,所以通过减小"initial heap size"而保持GC执行时"heap size" 小,就可以实现这个目标; 但保持两次GC执行间隔长也有利于性能,这个可以通过增加"initial heap size"实现.看来这两个指标是矛盾的.调节 "initial heap size"值就是试图找到它们的最优平衡点.通过方法(1)查看CPU消耗时间是最好的方法.但如果OS/400里没有安装付费软件 PT1(Performance Tools),就只能用方法(2)了.当然,别忘记最直观的应用吞吐量和响应时间.