若观察到Tomcat进程CPU使用率较高，并在GC日志中发现GC次数比较频繁、GC停顿时间长，说明需优化GC。
在第一篇 理解 Java GC 中我们学习了不同GC算法的处理过程，GC是如何工作的，什么是年轻代和老年代，JDK7中的5种GC类型，以及每种GC类型对性能的影响。
本文由CrowHawk(https://crowhawk.github.io/2017/08/21/jvm_4/)翻译，是Java GC调优的经典佳作。 本文翻译自Sangmin Lee发表在Cubrid上的"Become a Java GC Expert"系列文章的第三篇《How to Tune Java Garbage Collection》,本文的作者是韩国人，写在JDK 1.8发布之前，虽然有些地方有些许过时，但整体内容还是非常有价值的。译者此前也看到有人翻译了本文，发现其中有许多错漏生硬和语焉不详
本文由CrowHawk翻译，地址：如何优化Java GC「译」，是Java GC调优的经典佳作。
在分享《Spring Cloud之极端续租间隔时间的影响》 后，晓波同学问：由于心跳频率过高导致出现新对象过多？
没有经验的程序员经常认为Java的自动垃圾回收完全使他们免于担心内存管理。这是一个常见的误解：虽然垃圾收集器做得很好，但即使是最好的程序员也完全有可能成为严重破坏内存泄漏的牺牲品。让我解释一下。
注意到毛刺出现极其规律，每30分钟出现一个毛刺。考虑到这种规律性，并结合服务的流量较小（20 QPS）推测，可能是某个定时请求的接口进行了耗时操作，由于流量较小放大了平均耗时，继而出现了毛刺。但排查主调调用的接口，并没有发现定时的调用，从而否定了这种可能性。 排除服务外部的原因导致的毛刺，那么只剩下服务内部的原因了。该服务为JAVA应用，考虑到服务GC会导致应用暂停，使外部请求耗时异常增长；但是，并不能解释如此规律的毛刺。抱着“死马当活马医”的想法，使用如下命令
【简 介】 Java的堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，这些对象通过new、newarray、anewarray和multianewarray等指令建立，但是它们不需要程序代码来显式地释放。 引言 Java的堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，这些对象通过new、newarray、anewarray和multianewarray等指令建立，但是它们不需要程序代码来显式地释放。一般来说，堆的是由垃圾回收 来负责的，尽管JVM规范并不要求特殊的垃圾回收技术，甚至根本就不需要垃圾回收，但是由于内存的有限性，JVM在实现的时候都有一个由垃圾回收所管理的堆。垃圾回收是一种动态存储管理技术，它自动地释放不再被程序引用的对象，按照特定的垃圾收集算法来实现资源自动回收的功能。 垃圾收集的意义 在C++中，对象所占的内存在程序结束运行之前一直被占用，在明确释放之前不能分配给其它对象；而在Java中，当没有对象引用指向原先分配给某个对象的内存时，该内存便成为垃圾。JVM的一个系统级线程会自动释放该内存块。垃圾收集意味着程序不再需要的对象是"无用信息"，这些信息将被丢弃。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。事实上，除了释放没用的对象，垃圾收集也可以清除内存记录碎片。由于创建对象和垃圾收集器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆的一端，JVM将整理出的内存分配给新的对象。 垃圾收集能自动释放内存空间，减轻编程的负担。这使Java 虚拟机具有一些优点。首先，它能使编程效率提高。在没有垃圾收集机制的时候，可能要花许多时间来解决一个难懂的存储器问题。在用Java语言编程的时候，靠垃圾收集机制可大大缩短时间。其次是它保护程序的完整性， 垃圾收集是Java语言安全性策略的一个重要部份。 垃圾收集的一个潜在的缺点是它的开销影响程序性能。Java虚拟机必须追踪运行程序中有用的对象， 而且最终释放没用的对象。这一个过程需要花费处理器的时间。其次垃圾收集算法的不完备性，早先采用的某些垃圾收集算法就不能保证100%收集到所有的废弃内存。当然随着垃圾收集算法的不断改进以及软硬件运行效率的不断提升，这些问题都可以迎刃而解。 垃圾收集的算法分析 Java语言规范没有明确地说明JVM使用哪种垃圾回收算法，但是任何一种垃圾收集算法一般要做2件基本的事情：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。 大多数垃圾回收算法使用了根集(root set)这个概念；所谓根集就量正在执行的Java程序可以访问的引用变量的集合(包括局部变量、参数、类变量)，程序可以使用引用变量访问对象的属性和调用对象的方法。垃圾收集首选需要确定从根开始哪些是可达的和哪些是不可达的，从根集可达的对象都是活动对象，它们不能作为垃圾被回收，这也包括从根集间接可达的对象。而根集通过任意路径不可达的对象符合垃圾收集的条件，应该被回收。下面介绍几个常用的算法。 1、 引用计数法(Reference Counting Collector) 引用计数法是唯一没有使用根集的垃圾回收的法，该算法使用引用计数器来区分存活对象和不再使用的对象。一般来说，堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就满足了垃圾收集的条件。 基于引用计数器的垃圾收集器运行较快，不会长时间中断程序执行，适宜地必须 实时运行的程序。但引用计数器增加了程序执行的开销，因为每次对象赋给新的变量，计数器加1，而每次现有对象出了作用域生，计数器减1。 2、tracing算法(Tracing Collector) tracing算法是为了解决引用计数法的问题而提出，它使用了根集的概念。基于tracing算法的垃圾收集器从根集开始扫描，识别出哪些对象可达，哪些对象不可达，并用某种方式标记可达对象，例如对每个可达对象设置一个或多个位。在扫描识别过程中，基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器. 3、compacting算法(Compacting Collector) 为了解决堆碎片问题，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的过程中，算法将所有的对象移到堆的一
本文基于某环境一个真实Case，它配置了非常极端的续租间隔时间。虽然知道服务注册的基本知识，但未深入了解过，正好基于这个Case学习下。
1、-XX:MaxGCPauseMillis=nnn ：不能设置过小，会阻碍吞吐量，如果不设置，暂停时间依赖heap中活动数据量。
Kubernetes虽然成为了标准，但是不同的运维在实施的时候，或者说不同的公司在使用的时候是千奇百怪的，我们也会经常在一些Kubernetes社区群里看到一些千奇百怪的问题，这些问题除了提升自身硬实力之外，也要树立一些做事的规范。这里从下面四个方面说一些个人的看法和见解，这些都是我自己在实际工作中运用的，说的不对的地方请指正。
如果应用程序的执行时间越来越长，或者操作系统的执行速度越来越慢，这可能是内存泄漏的迹象。换句话说，正在分配虚拟内存，但在不再需要时不会返回。最终应用程序或系统内存不足，应用程序异常终止。
以上的这些参数我们经常会在很多情况下用到多个的组合，比如我们在用JProfiler进行跟踪监控时，需要在被监控java启动参数中加上如下配置：-agentlib:jprofilerti=port=8849 -Xbootclasspath/a:/usr/local/jprofiler5/bin/agent.jar其中就用到两个-agentlib和-X参数，bootclasspath参数的详细信息将会在非标准参数中详细说明。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
