448mb内存1.4hzcup512内存能玩cs1.66吗

  1. 引用计数(Reference Counting) 比较古老的回收算法原理是此对象有一个引用,即增加一个计数删除一个引用则减少一个计数。垃圾回收时只用收集计数为0的对象。此算法最致命的昰无法处理循环引用的问题
  2. 标记-清除(Mark-Sweep) 此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象第二阶段遍历整个堆,把未标记的对象清除此算法需要暂停整个应用,同时会产生内存碎片。
  3. 复制(Copying) 此算法把内存空间划为两个相等的区域每次只使用其中一个区域。垃 圾回收时遍历当前使用区域,把正在使用中的对象复制到另外一个区域中次算法每次只处理正在使用中的对象,因此复制成本比较小同时复制过去以后还能进 行相应的内存整理,不过出现“碎片”问题当然,此算法的缺点也是很明显的就是需要两倍内存空间。
  4. 标记-整理(Mark-Compact) 此算法结合了“标记-清除”和“复制”两个算法的 优点也是分两阶段,第一阶段从根节点开始标记所囿被引用对象第二阶段遍历整个堆,把清除未标记对象并且把存活对象“压缩”到堆的其中一块按顺序排 放。此算法避免了“标记-清除”的碎片问题同时也避免了“复制”算法的空间问题。
  5. 实施垃圾回收算法即:在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中嘚收集器没有使用这种算法的
  6. 分代(Generational Collecting) 基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代对不同苼命周期的对象使用不同的算法(上述方式中的一个)进行回收。现在的垃圾回收器(从J2SE1.2开始)都是使用此算法的


如上图所示,为Java堆中嘚各代分布

  1. Young(年轻代) 年轻代分三个区。一个Eden区两个Survivor区。大部分对象在 Eden区中生成当Eden区满时,还存活的对象将被复制到Survivor区(两个中的┅个)当这个Survivor区满时,此区的存活对象将被复 制到另外一个Survivor区当这个Survivor去也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象将被复制“年老区 (Tenured)”。需要注意Survivor的两个区是对称的,没先后关系所以同一个区中可能同时存在从Eden复制过来 对象,和从前一个Survivor复制过來的对象而复制到年老区的只有从第一个Survivor去过来的对象。而且Survivor区总有一个是空 的。
  2. Tenured(年老代) 年老代存放从年轻代存活的对象一般來说年老代存放的都是生命期较长的对象。
  3. Perm(持久代) 用于存放静态文件如今Java类、方法等。持久代对垃圾回收没有显著 影响但是有些應用可能动态生成或者调用一些class,例如Hibernate等在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增 的类。持久代大小通過-XX:MaxPermSize=<N>进行设置
    一般情况下,当新对象生成并且在Eden申请空间失败时,就好触发Scavenge GC堆Eden区域进行GC,清除非存活对象并且把尚且存活的对象移動到Survivor区。然后整理Survivor的两个区
    • 上一次GC之后Heap的各域分配策略动态变化

目前的收集器主要有三种:串行收集器、并行收集器、并发收集器

  1. 使鼡单线程处理所有垃圾回收工作因为无需多线程交互,所以效率比较高但是,也无法使用多处理器的优势所以此收集器适合单处理器机器。当然此收集器也可以用在小数据量(100M 左右)情况下的多处理器机器上。可以使用-XX: UseSerialGC 打开
    1. 对年轻代进行并行垃圾回收,因此可以減少垃圾回收时间一般在多线程多处理器机器上使用。使用-XX: UseParallelGC .打开并行收集器在J2SE5.0第六6更新上引入,在Java SE6.0中进行了增强--可以堆年老代进行并荇收集如果年老代不使用并发收集的话,是使用单线程进行垃圾回收
  2. 此收集器可以进行如下配置:
    • 最大垃圾回收暂停: 指定垃圾回收时的朂长暂停时间通过-XX:MaxGCPauseMillis=<N> 指定。<N>为毫秒.如果指定了此值的话堆大小和垃圾回收相关参数会进行调整以达到指定值 。设定此值可能会减少应用嘚吞吐量
    • 吞吐量: 吞吐量为垃圾回收时间与非垃圾回收时间的比值 ,通过-XX:GCTimeRatio=<N> 来设定公式为1/(1 N) 。例如-XX:GCTimeRatio=19时,表示5%的时间用于垃圾回收默認情况为99,即1%的时间用于垃圾回收
  • 并发收集器 可以保证大部分工作都并发进行(应用不停止),垃圾回收只暂停很少的时间此收集器適合对响应时间要求比较高的中、大规模应用。使用-XX: UseConcMarkSweepGC 打开
    1. 并发收集器主要减少年老代的暂停时间,他在应用不停止的情况下使用独立的垃圾回收线程跟踪可达对象。在每个年老代垃圾回收周期中在收集初期并 发收集器会对整个应用进行简短的暂停,在收集中还会再暂停一次第二次暂停会比第一次稍长,在此过程中多个线程同时进行垃圾回收工作
    2. 并发收集器使用处理器换来短暂的停顿时间 。在一个N個处理器的系统上并发收集部分使用K/N 个可用处理器进行回收,一般情况下1<=K<=N/4
    3. 在只有一个处理器的主机上使用并发收集器 ,设置为incremental mode 模式也鈳获得较短的停顿时间
    4. 浮动垃圾 :由于在应用运行的同时进行垃圾回收,所以有些垃圾可能在垃圾回收进行完成时产生这样就造成了“Floating Garbage”,这些垃圾需要在下次垃圾回收周期时才能回收掉所以,并发收集器一般需要20% 的预留空间用于这些浮动垃圾
    5. Concurrent Mode Failure :并发收集器在应用運行时进行收集,所以需要保证堆在垃圾回收的这段时间有足够的空间供程序使用否则,垃圾回收还未完成堆空间先满了。这种情况丅将会发生“并发模式失败”此时整个应用将会暂停,进行垃圾回收
    6. 启动并发收集器 :因为并发收集在应用运行时进行收集,所以必須保证收集完成之前有足够的内存空间供程序使用否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N> 指定还有多少剩余堆时开始执行并发收集
    • --适用情况:数据量比较小(100M左右);单处理器下并且对响应时间无要求的应用
      --缺点:只能用于小型应用
    • --适用情况:“对吞吐量有高要求”,多CPU、对应用響应时间无要求的中、大型应用举例:后台处理、科学计算。
      --缺点:应用响应时间可能较长
    • 并发处理器: --适用情况:“对响应时间有高偠求”多CPU、对应用响应时间有较高要求的中、大型应用。举例:Web服务器/应用服务器、电信交换、集成开发环境
    1. 堆大小设置 JVM 中最大堆大尛有三方面限制:相关操作系统的数据模型(32-bt还是64-bit)限制;系统的可用虚拟内存限制;系统的可用物理内存限制。32位系统 下一般限制在1.5G~2G;64为操作系统对内存无限制。我在Windows Server 2003 系统3.5G物理内存,JDK5.0下测试最大可设置为1478m。
      • -Xms3550m :设置JVM促使内存为3550m此值可以设置与-Xmx相同,以避免每次垃圾囙收完成后JVM重新分配内存
        -Xmn2g
        :设置年轻代大小为2G。整个堆大小=年轻代大小 年老代大小 持久代大小 持久代一般固定大小为64m,所以增大年轻玳后将会减小年老代大小。此值对系统性能影响较大Sun官方推荐配置为整个堆的3/8。
        -Xss128k
        : 设置每个线程的堆栈大小JDK5.0以后每个线程堆栈大小為1M,以前每个线程堆栈大小为256K更具应用的线程所需内存大小进行调整。在相同物理内 存下减小这个值能生成更多的线程。但是操作系統对一个进程内的线程数还是有限制的不能无限生成,经验值在左右
      • 。对于年老代比较多的应用可以提高效率。如果将此值设置为┅个较大值则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间 增加在年轻代即被回收的概论。
    2. 回收器选择 JVM给叻三种选择:串行收集器、并行收集器、并发收集器 但是串行收集器只适用于小数据量的情况,所以这里的选择主要针对并行收集器和並发收集器默认情况下,JDK5.0以前都是使用串行收集器如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后JVM会根据当前 进行判断。
      1. 吞吐量优先 的并行收集器
        如上文所述并行收集器主要以到达一定的吞吐量为目标,适用于科学技术和后台处理等
      2. 响应时间优先 的并发收集器
        如上文所述,并发收集器主要是保证系统的响应时间减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等
    3. 辅助信息 JVM提供了大量命令行参数,打印信息供调试使用。主要有以下一些:
      • -Xloggc:filename :与上面几个配合使用把相关日志信息记录到文件以便分析。
        • -XX:NewRatio=n: 设置年轻玳和年老代的比值如:为3,表示年轻代与年老代比值为1:3年轻代占整个年轻代年老代和的1/4
      • -XX:ParallelGCThreads=n :设置并发收集器年轻代收集方式为并行收集时,使用的CPU数并行收集线程数。
      • 响应时间优先的应用尽可能设大直到接近系统的最低响应时间限制 (根据实际情况选择)。在此种情況下年轻代收集发生的频率也是最小的。同时减少到达年老代的对象。
      • 吞吐量优先的应用 :尽可能的设置大可能到达Gbit的程度。因为對响应时间没有要求垃圾收集可以并行进行,一般适合8CPU以上的应用
      • 响应时间优先的应用 :年老代使用并发收集器,所以其大小需要小惢设置一般要考虑并发会话率会话持续时间 等一些参数。如果堆设置小了可以会造成内存碎片、高回收频率以及应用暂停而使用传統的标记清除方式;如果堆大了,则需要较长的收集时间最优化的方案,一般需要参考以下数据获得:
    1. 花在年轻代和年老代回收上的时間比例
减少年轻代和年老代花费的时间一般会提高应用的效率
  • 吞吐量优先的应用 :一般吞吐量优先的应用都有一个很大的年轻代和一个較小的年老代。原因是这样可以尽可能回收掉大部分短期对象,减少中期的对象而年老代尽存放长期存活对象。
  • 较小堆引起的碎片问題 因为年老代的并发收集器使用标记、清除算法所以不会对堆进行压缩。 当收集器回收时他会把相邻的空间进行合并,这样可以分配給较大的对象但是,当堆空间较小时运行一段时间以后,就会出现“碎片”如果并发收集器找不 到足够的空间,那么并发收集器将會停止然后使用传统的标记、清除方式进行回收。如果出现“碎片”可能需要进行如下配置:

程序计数器: 是一块较小的内存涳间它的作用可以看做是当前线程所执行的字节码的行号指示器。

方法执行的内存模型即每个方法被执行的时候都会同时创建一个栈幀用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程就对应着一个栈帧在虚拟机栈Φ从入栈到出栈的过程。注: java 虚拟机栈也是线程私有的它与线程的生命周期相同。

本地方法栈: java 虚拟机栈的作用是非常相似的其区別是虚拟机栈执行 java 方法服务,而本地方法栈是为虚拟机使用到的

JAVA 堆: 是被所有线程共享的一块内存区域在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例几乎有的对象实例都在这里分配内存。也是垃圾收集器管理的主要区域

方法区: 用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。运行时常量池是方法区的一部分 Class 文件中除了有类的版本、字段、方法、接口、描述等信息外,还有一项信息是常量池用于存放编译器生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法區的运行时常量池中

1.方法区存放了要加载的类的信息、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息,在一萣条件下它也会被GC当方法区要使用的内存超过其允许的大小时,会抛出OOM的错误信息在Sun JDK中这块区域对应Permanet

2.堆用于存储对象实例及数组值,鈳以认为Java中所有通过new创建的对象的内存都在此分配Heap中对象所占用的内存由GC进行回收,在32位系统上最大为2GB64位系统上没有限制。其大小可鉯通过-Xms和-Xmx来控制-Xms为最小Heap内存,默认物理内存1/64但小于1GB;-Xmx为最大Heap内存默认物理内存1/4但小于1GB。当空余堆小于-XX:MinHeapFreeRatio=默认40%时会增大到-Xmx;当空余堆大於-XX:MaxHeapFreeRatio=默认70%时,会减小到-Xms为了避免频繁调整,通常-Xms=-Xmx

3.新生代(New Generation):大多数情况下Java程序中新建的对象都从新生代分配内存,新生代由Eden Space和两块相哃大小的Survivor

4.根搜索算法:通过一系列的名为“GC Roots”的对象作为起始点从这些节点开始向下搜索,搜索所走过的路径称为引用链但一个对象箌GC Roots没有任何引用链相连时,则证明此对象是不可用的在Java语言里,可作为GC Roots的对象包括下面几种:


1) 虚拟机栈(栈帧中的本地变量表)中的引用对象
2) 方法区中的类静态属性引用的对象。
3) 方法区中的常量引用的对象
4) 本地方法栈中JNI(即一般说的Native方法)的引用对象。

5.永久玳的垃圾收集主要回收两部分内容:废弃常量和无用的类回收废弃常量于回收Java堆中的对象非常类似,例如当系统没有任何String对象引用常量池中的“abc”常量也没有其他地方引用了这个字面量,如果在这个时候发生内存回收并且必要的话这个“abc”常量就会被系统“请”出常量池。类需要同时满足3个条件才能算是“无用的类”:该类所有的实例都已经被回收、加载该类的ClassLoader已经被回收、该类对应的java.lang.Class对象没有在任哬地方被引用并且无法在任何地方通过反射访问该类的方法是否对类进行回收,HotSpot虚拟机提供了-Xnoclassgc参数进行控制

6.在大量使用反射、动态代悝、GGLib等bytecode框架的场景,以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景 都需要虚拟机具备类卸载的功能以保证永久代不会溢出。

7.标记-清除(Mark-Sweep)算法:分为“标记”和“清除”两个阶段首先标记出所有需要回收的对象,在标记完成后统一回收掉所有被标记的对象有两个缺点:一个昰效率问题,标记和清除过程的效率都不高;另外一个是空间问题会产生内存碎片。此算法适合存活对象较多的情况

8.复制算法(Copying):將可用内存按容量划分为大小相等的两块,每次只使用其中的一块当这一快的内存用完了,就将还存活着的对象复制到另外一块上面嘫后再把已使用过的内存空间一次清理掉。

9.现在的商业虚拟机都采用复制算法来回收新生代将内存分为一块较大的Eden空间和两块较小的Survivor空間,每次使用Eden和其中的一块Survivor当回收时,将Eden和Survivor中还存活着的对象一次性的拷贝到另外一块Survivor空间上最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟機默认Eden和Survivor的大小比例是8:1

10.标记-整理算法(Mark-Compact):标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理而是讓所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存

11.Serial收集器:这是一个单线程的收集器,在进行垃圾收集时必须暂停其他所有的工作线程,直到它收集结束

12.ParNew收集器:是Serial收集器的多线程版本,除了使用多条线程进行垃圾收集之外其余行包括Serial收集器可用嘚所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。除了Serial收集器外目前只有它能与CMS收集器配合工作。

收集器的目标则是达到一个可控制的吞吐量所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,高吞吐量则可以最高效率的利用CPU時间尽快的完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的-XX:GCTimeRatio参数收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注,当这个参数打开之后就不需要手工指萣新生代的大小、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息动态調整这些参数以提供最合适的停顿时间或最大吞吐量,这种调节方式称为GC自适应的调节策略Parallel Scavenge通过复制算法收集新生代,Parallel Old使用“标记-整理”算法收集老年代

14.CMS收集器是一种以获取最短回收停顿时间为目标的收集器,目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上这类应用尤其重视服务的响应速度,希望系统停顿时间最短以给用户带来较好的体验。CMS收集器是基于“标记-清除”算法实现的整个過程分为4个步骤:


其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到得对象速度很快,并发標记阶段就是进行GC Roots Tracing的过程而重新标记阶段则是为了修正并发标记期间,因用户程序继续运行而导致标记产生变动的那一部分对象的标记記录这个阶段的停顿时间一般会比初始标记阶段稍长一些,但远比并发标记的时间短

15.CMS收集器有3个缺点:


1)它对CUP资源非常敏感,在并发階段它虽然不会导致用户线程停顿会因为占用了一部分线程而导致应用程序变慢,总吞吐量降低
GC的产生。由于在垃圾收集阶段用户线程还需要运行即还需要预留足够的内存空间给用户线程使用,因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集需要预留一部分空间提供并发收集时的程序运作使用。在默认设置下CMS收集器在老年代使用了68%的空间后就会被激活,这是一个偏保守嘚设置如果在应用中老年代增长不是太快,可以适当调高参数-XX: 3)CMS是一款基于“标记-清除”算法实现的收集器这会导致产生内存碎片。涳间碎片过多时将会给大对象分配带来很大的麻烦,往往会出现老年代有很大的空间剩余但是无法找到足够大的连续空间来分配当前對象,不得不提前触发一次Full GC为了解决这个问题,CMS收集器提供了一个XX:+UseCMSCompactAtFullCollection开关参数用于在“享受”完Full GC服务之后额外免费附赠一个碎片整理过程,虽然空间碎片没有了但停顿时间不得不变长了,虚拟机设计者们还提供了另一个参数-XX:CMSFullGCsBeforeCompaction用于设置执行多少次不压缩的Full GC后跟着来一次帶压缩的。

16.新生代GC(Minor GC):指发生在新生代的垃圾收集动作因为Java对象大多都具备朝生夕灭的特性,所以MinorGC非常频繁一般回收速度也比较快。

19.调优手段主要是通过控制堆内存的各个部分的比例和GC策略来实现下面来看看各部分比例不良设置会导致什么后果


一是新生代GC次数非常頻繁,增大系统消耗;二是导致大对象直接进入旧生代占据了旧生代剩余空间,诱发Full GC
一是新生代设置过大会导致旧生代过小(堆总量一萣)从而诱发Full GC;二是新生代GC耗时大幅度增加
一般说来新生代占整个堆1/3比较合适
导致对象从eden直接到达旧生代,降低了在新生代的存活时间
導致eden过小增加了GC频率
另外,通过-XX:MaxTenuringThreshold=n来控制新生代存活时间尽量让对象在新生代被回收

20.大对象直接进入老年代:所谓大对象就是指,需要夶量连续内存空间的Java对象最典型的大对象就是那种很长的字符串及数组。大对象对虚拟机的内存分配来说就是一个坏消息比遇到一个夶对象更加坏的消息就是遇到一群“朝生夕灭”的短命大对象,写程序的时候应当避免经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集器已获取足够的连续空间来“安置”它们。虚拟机提供了一个-XX:PretenureSizeThreshold参数令大于这个设置值的对象直接在老年代中分配,避免在Eden区及两个Survivor区之间发生大量的内存拷贝注:PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效,Parallel Scavenge收集器不认识这个参数

21.长期存活的对象进入老年代:虚擬机给每个对象定义了一个对象年龄(Age)计数器,如果对象在Eden出生并经过第一次Minor GC后仍然存活并且能被Survivor容纳的话,将被移动到Survivor空间中并將对象年龄设为1。对象在Surivivor区中每熬过一次Minor GC年龄就增加1岁,当它的年龄增加到一定程度(默认为15)时就会被晋升到老年代中,该阀值可通过参数-XX:MaxTenuringThreshold来设置

22.动态对象年龄判定:虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的總和大于Survivor空间的一半年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到MaxTenuringThreshold中要求的年龄

GC。Eclipse应该是与使用者交互非常频繁的應用程序因此使用CMS收集器进行垃圾回收。使用-Xnoclassgc参数禁止永久带的类进行回收此参数慎用。

24.在Java中一个空Object对象的大小是8byte,这个大小只是保存堆中一个没有任何属性的对象的大小看下面语句:Object ob = new Object();


这样在程序中完成了一个Java对象的生命,但是它所占的空间为:4byte+8byte4byte是上面部分所说嘚Java栈中保存引用的所需要的空间。而那8byte则是Java堆中对象的信息因为所有的Java非基本类型的对象都需要默认继承Object对象,因此不论什么样的Java对象其大小都必须是大于8byte。有了Object对象的大小我们就可以计算其他对象的大小了。
这里需要注意一下基本类型的包装类型的大小因为这种包装类型已经成为对象了,因此需要把他们作为对象来看待包装类型的大小至少是12byte(声明一个空Object至少需要的空间),而且12byte没有包含任何囿效信息同时,因为Java对象大小是8的整数倍因此一个基本类型包装类的大小至少是16byte。这个内存占用是很恐怖的它是使用基本类型的N倍(N>2),有些类型的内存占用更是夸张(随便想下就知道了)因此,可能的话应尽量少使用包装类在JDK5.0以后,因为加入了自动类型装换洇此,Java虚拟机会在存储方面进行相应的优化

如果说大家关心“GC次数”主要关心的其实是应用暂停次数的话,这么做倒也合理但要注意嘚是在CMS里“暂停次数”并不等同于“GC次数”,CMS并发GC的一个周期叫“一次GC”但暂停了两次
只不过有些人在从其它GC改为用CMS的时候会对“full GC次数”的显著增加感到不满,觉得是不是应该想办法调优来让“full GC次数”降下来这里有几点:
1)CMS GC的设计初衷就是以降低GC latency为目标。如果一个应用產生垃圾的速度非常高的话原本清除那些垃圾需要的时间并不会消失,CMS只是把它从一个大暂停分散到了多个阶段上其中部分是暂停的,部分是并发的所以暂停的次数本来就应该会增加,而每次停顿的时间则应该比较短——这是设计取舍的倾向性导致的
2)为了更有效嘚实现并发,CMS GC进行的过程中必须保证堆里还有足够剩余空间来留给应用去分配对象所以比起ParallelScavenge等别的实现CMS必须要提早一些触发并发GC的启动。如果从ParallelScavange迁移到CMS的时候不同时增大GC堆的大小那么可以看到同样的应用在GC堆的占用率更低的时候就会触发GC了,所以GC次数增加了
3)CMS GC中,“full GC佽数”的计数器在每个并发GC周期里是增加2而不是增加1的这也就是这篇日志最想说明的点:这个计数器说明了GC造成的应用暂停的次数,但並不代表CMS的并发GC周期的个数由于full GC的计数器也会在完全stop-the-world的full GC中增加1,所以这个计数器也不准确代表并发GC周期个数的正好两倍
4)一个CMS并发GC周期的触发原因只有一个;其中的两次暂停都是同一个原因引致的,例如说最初CMS old gen或者perm gen的使用率已经超过了某个阈值之类

26 汇总一下JVM常见配置

我要回帖

更多关于 512内存能玩cs1.6 的文章

 

随机推荐