├── 01_01_Java-GC-counting-references1.png ├── 01_02_Java-GC-cyclical-dependencies.png ├── 01_03_Java-GC-mark-and-sweep.png ├── 01_What_Is_Garbage_Collection.md ├── 01_What_Is_Garbage_Collection_CN.md ├── 02_01_fragmented-vs-compacted-heap.png ├── 02_02_object-age-based-on-GC-gen-hypothesis.png ├── 02_03_java-heap-eden-survivor-old.png ├── 02_04_TLAB-in-Eden-memory.png ├── 02_05_how-java-gc-works.png ├── 02_Garbage_Collection_in_Java.md ├── 02_Garbage_Collection_in_Java_CN.md ├── 03_01_Java-GC-mark-and-sweep.png ├── 03_02_GC-sweep.png ├── 03_03_GC-mark-sweep-compact.png ├── 03_04_GC-mark-and-copy-in-Java.png ├── 03_GC_Algorithms_Basics.md ├── 03_GC_Algorithms_Basics_CN.md ├── 04_01_serial-gc-in-young-generation.png ├── 04_02_serial-gc-in-old-gen-java.png ├── 04_03_ParallelGC-in-Young-Generation-Java.png ├── 04_04_Java-ParallelGC-in-Old-Generation.png ├── 04_05_ParallelGC-in-Young-Generation-Java.png ├── 04_06_g1-06.png ├── 04_07_g1-07.png ├── 04_08_g1-08.png ├── 04_09_g1-09.png ├── 04_10_g1-10.png ├── 04_11_g1-011.png ├── 04_12_g1-02.png ├── 04_13_g1-03.png ├── 04_14_g1-04.png ├── 04_15_g1-05-v2.png ├── 04_GC_Algorithms_Implementations.md ├── 04_GC_Algorithms_Implementations_CN.md ├── 05_01_assembly-line01-compact.jpg ├── 05_02_assembly-line02-compact.jpg ├── 05_GC_Tuning_Basics.md ├── 05_GC_Tuning_Basics_CN.md ├── 06_01_JMX-view.png ├── 06_02_JMX-view-Mbean.png ├── 06_03_jvmsualvm-garbage-collection-monitoring.png ├── 06_04_gcviewer-screenshot.png ├── 06_05_gviewer-screenshot-pause.png ├── 06_06_gcviewer-screenshot-eventdetails.png ├── 06_07_01_trace.png ├── 06_07_jvisualvm-top-objects.png ├── 06_08_jvisualvm-allocation-traces.png ├── 06_GC_Tuning_Tooling.md ├── 06_GC_Tuning_Tooling_CN.md ├── 07_01_how-java-garbage-collection-works.png ├── 07_GC_Tuning_In_Practice.md ├── 07_GC_Tuning_In_Practice_CN.md ├── GC_HANDBOOK.md ├── Java_GC_Hanbook_CN.pdf ├── Plumbr_Handbook_Java_Garbage_Collection.pdf └── README.md /01_01_Java-GC-counting-references1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/01_01_Java-GC-counting-references1.png -------------------------------------------------------------------------------- /01_02_Java-GC-cyclical-dependencies.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/01_02_Java-GC-cyclical-dependencies.png -------------------------------------------------------------------------------- /01_03_Java-GC-mark-and-sweep.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/01_03_Java-GC-mark-and-sweep.png -------------------------------------------------------------------------------- /01_What_Is_Garbage_Collection.md: -------------------------------------------------------------------------------- 1 | > #### 说明: 2 | > 3 | > 在本文中, `Garbage Collection` 翻译为 “`垃圾收集`”, `garbage collector` 翻译为 “`垃圾收集器`”; 4 | > 5 | > 一般认为, **垃圾回收** 和 **垃圾收集** 是同义词。 6 | > 7 | > `Minor GC` 翻译为： **小型GC**; 而不是 次要GC 8 | > 9 | > `Major GC` 翻译为： **大型GC**; 而不是 主要GC 10 | > 11 | > 原因在于,大部分情况下, 发生在年轻代的 `Minor GC` 次数会很多,翻译为次要GC明显不对。 12 | > 13 | > `Full GC` 翻译为： **完全GC**; 为了清晰起见,一般直接译为 Full GC,读者明白即可; 其中大型GC和完全GC差不多, 这些术语出自官方的各种分析工具和垃圾收集日志。并不是很统一。 14 | 15 | 16 | 17 | # 1. 垃圾收集简介 18 | 19 | 20 | At the first sight, garbage collection should be dealing with what the name suggests – finding and throwing away the garbage. In reality it is doing exactly the opposite. Garbage Collection is tracking down all the objects which are still used and marks the rest as garbage. Bearing this in mind, we start digging into more details of how the process of automated memory reclamation called ‘Garbage Collection’ is implemented for Java Virtual Machine. 21 | 22 | 23 | 顾名思义,垃圾收集(Garbage Collection)的意思就是 —— 找到垃圾并进行清理。但现有的垃圾收集实现却恰恰相反: **垃圾收集器跟踪所有正在使用的对象,并把其余部分当做垃圾**。记住这一点以后, 我们再深入讲解内存自动回收的原理，探究 JVM 中垃圾收集的具体实现, 。 24 | 25 | 26 | 27 | Instead of rushing into specifics, we shall start from the very beginning, explaining the general nature of garbage collection and the core concepts and approaches. 28 | 29 | 30 | 我们不抠细节, 先从基础开始, 介绍垃圾收集的一般特征、核心概念以及实现算法。 31 | 32 | 33 | >**Disclaimer**: This content focuses on Oracle Hotspot and OpenJDK behaviour. In other runtimes or even on other JVMs, such as jRockit or IBM J9, some of the aspects covered in this handbook can behave differently. 34 | 35 | 36 | 37 | > **免责声明**: 本文主要讲解 Oracle Hotspot 和 OpenJDK 的行为。对于其他JVM, 如 jRockit 或者 IBM J9, 在某些方面可能会略有不同。 38 | 39 | 40 | 41 | ## Manual Memory Management 42 | 43 | ## 手动内存管理(Manual Memory Management) 44 | 45 | 46 | Before we can start covering Garbage Collection in its modern form, let’s do a quick recap of days where you had to manually and explicitly allocate and free memory for your data. And if you ever forgot to free it, you would not be able to reuse the memory. The memory would be claimed but not used. Such a scenario is called a **`memory leak`**. 47 | 48 | 当今的自动垃圾收集算法极为先进, 但我们先来看看什么是手动内存管理。在那个时候, 如果要存储共享数据, 必须显式地进行 内存分配(allocate)和内存释放(free)。如果忘记释放, 则对应的那块内存不能再次使用。内存一直被占着, 却不再使用，这种情况就称为**内存泄漏**(`memory leak`)。 49 | 50 | 51 | Here is a simple example written in C using manual memory management: 52 | 53 | 以下是用C语言来手动管理内存的一个示例程序: 54 | 55 | 56 | int send_request() { 57 | size_t n = read_size(); 58 | int *elements = malloc(n * sizeof(int)); 59 | 60 | if(read_elements(n, elements) < n) { 61 | // elements not freed! 62 | return -1; 63 | } 64 | 65 | // … 66 | 67 | free(elements) 68 | return 0; 69 | } 70 | 71 | 72 | As we can see, it is fairly easy to forget to free memory. Memory leaks used to be a lot more common problem than today. You could only really fight them by fixing your code. Thus, a much better approach would be to automate the reclamation of unused memory, eliminating the possibility of human error altogether. Such automation is called **`Garbage Collection`** (or GC for short). 73 | 74 | 75 | 可以看到,如果程序很长,或者结构比较复杂, 很可能就会忘记释放内存。内存泄漏曾经是个非常普遍的问题, 而且只能通过修复代码来解决。因此,业界迫切希望有一种更好的办法,来自动回收不再使用的内存,完全消除可能的人为错误。这种自动机制被称为 **垃圾收集**(`Garbage Collection`,简称GC)。 76 | 77 | 78 | 79 | ### Smart Pointers 80 | 81 | ### 智能指针(Smart Pointers) 82 | 83 | 84 | One of the first ways to automate garbage collection was built upon reference counting. For each object, you simply know how many times it is referred to and when that count reaches zero the object can be safely reclaimed. A well-known example of that would be the shared pointers of C++: 85 | 86 | 87 | 第一代自动垃圾收集算法, 使用的是**引用计数**(reference counting)。针对每个对象, 只需要记住被引用的次数, 当引用计数变为0时, 这个对象就可以被安全地回收(reclaimed)了。一个著名的示例是 C++ 的共享指针(shared pointers): 88 | 89 | 90 | 91 | int send_request() { 92 | size_t n = read_size(); 93 | shared_ptr> elements 94 | = make_shared>(); 95 | 96 | if(read_elements(n, elements) < n) { 97 | return -1; 98 | } 99 | 100 | return 0; 101 | } 102 | 103 | 104 | The `shared_ptr` that we are making use of keeps track of the number of references to it. This number increases as you pass it around and decreases as it leaves scope. As soon as the number of references reaches zero, the `shared_ptr` automatically deletes the underlying vector. This example, as one of our readers points out, is not exactly prevalent in the real world, but it is enough for demonstrational purposes. 105 | 106 | 107 | `shared_ptr` 被用来跟踪引用的数量。作为参数传递时这个数字加1, 在离开作用域时这个数字减1。当引用计数变为0时, `shared_ptr` 自动删除底层的 vector。需要向读者指出的是，这种方式在实际编程中并不常见, 此处仅用于演示。 108 | 109 | 110 | 111 | 112 | ## Automated Memory Management 113 | 114 | ## 自动内存管理(Automated Memory Management) 115 | 116 | 117 | In the C++ code above, we still had to explicitly say when we want to have memory management to be taken care of. But what if we could make all the objects behave this way? That would be very handy, since the developers no longer have to think about cleaning up after themselves. The runtime will automatically understand that some memory is no longer used and frees it. In other words, it automatically **collects the garbage**. The first garbage collector was created in 1959 for Lisp and the technology has only advanced since then. 118 | 119 | 上面的C++代码中,我们要显式地声明什么时候需要进行内存管理。但不能让所有的对象都具备这种特征呢? 那样就太方便了, 开发者不再耗费脑细胞, 去考虑要在何处进行内存清理。运行时环境会自动算出哪些内存不再使用，并将其释放。换句话说, **自动进行收集垃圾**。第一款垃圾收集器是1959年为Lisp语言开发的, 此后 Lisp 的垃圾收集技术也一直处于业界领先水平。 120 | 121 | 122 | 123 | 124 | ### Reference Counting 125 | 126 | ### 引用计数 127 | 128 | 129 | The idea that we have demonstrated with the shared pointers of C++ can be applied to all objects. Many languages such as Perl, Python or PHP take this approach. This is best illustrated with a picture: 130 | 131 | 132 | 刚刚演示的C++共享指针方式, 可以应用到所有对象。许多语言都采用这种方法, 包括 Perl、Python 和 PHP 等。下图很好地展示了这种方式: 133 | 134 | 135 | 136 | ![](01_01_Java-GC-counting-references1.png) 137 | 138 | 139 | The green clouds indicate that the object that they point to is still in use by the programmer. Technically, these may be things like a local variable in the currently executing method or a static variable or something else. It may vary from programming language to programming language so we will not focus on it here. 140 | 141 | 142 | 图中绿色的云(GC ROOTS) 表示程序正在使用的对象。从技术上讲, 这些可能是当前正在执行的方法中的局部变量，或者是静态变量一类。在某些编程语言中,可能叫法不太一样,这里不必抠名词。 143 | 144 | 145 | 146 | The blue circles are the objects in memory as you can see by the number of references to them. Finally, the grey circles are objects which are not referenced from any of the scopes. The grey objects are thus garbage and could be cleaned by the Garbage Collector. 147 | 148 | 149 | 蓝色的圆圈表示可以引用到的对象, 里面的数字就是引用计数。然后, 灰色的圆圈是各个作用域都不再引用的对象。灰色的对象被认为是垃圾, 随时会被垃圾收集器清理。 150 | 151 | 152 | 153 | This all looks really good, does it not? Well, it does, but the whole method has a huge drawback. It is quite easy to end up with a **`detached cycle`** of objects none of which are in scope yet due to cyclic references the count of their reference is not zero. Here’s an illustration: 154 | 155 | 156 | 看起来很棒, 是吧! 但这种方式有个大坑, 很容易被**循环引用**(`detached cycle`) 给搞死。任何作用域中都没有引用指向这些对象，但由于循环引用, 导致引用计数一直大于零。如下图所示: 157 | 158 | 159 | ![](01_02_Java-GC-cyclical-dependencies.png) 160 | 161 | See? The red objects are in fact garbage that the application does not use. But due to the limitations of reference counting there is still a memory leak. 162 | 163 | 164 | 看到了吗? 红色的对象实际上属于垃圾。但由于引用计数的局限, 所以存在内存泄漏。 165 | 166 | 167 | 168 | There are some ways to overcome this, such as using special ‘weak’ references or applying a separate algorithm for collecting cycles. The aforementioned languages – Perl, Python and PHP – all handle cycles in one way or another, but this is outside the scope of this handbook. Instead, we will start investigating the approach taken by the JVM in more details. 169 | 170 | 171 | 172 | 当然也有一些办法来应对这种情况, 例如 “弱引用”(‘weak’ references), 或者使用另外的算法来排查循环引用等。前面提到的 Perl、Python 和PHP 等语言, 都使用了某些方式来解决循环引用问题, 但本文不对其进行讨论。下面介绍JVM中使用的垃圾收集方法。 173 | 174 | 175 | 176 | 177 | ### Mark and Sweep 178 | 179 | ### 标记-清除(Mark and Sweep) 180 | 181 | 182 | First of all, the JVM is more specific about what constitutes reachability of an object. Instead of the vaguely defined green clouds that we saw on earlier chapters, we have a very specific and explicit set of objects that are called the **`Garbage Collection Roots`**: 183 | 184 | 首先, JVM 明确定义了什么是对象的可达性(reachability)。我们前面所说的绿色云这种只能算是模糊的定义, JVM 中有一类很明确很具体的对象, 称为 垃圾收集根元素(Garbage Collection Roots)，包括: 185 | 186 | 187 | 188 | - 局部变量(Local variables) 189 | - 活动线程(Active threads) 190 | - 静态域(Static fields) 191 | - JNI引用(JNI references) 192 | - 其他对象(稍后介绍 ...) 193 | 194 | 195 | 196 | 197 | The method used by JVM to track down all the reachable (live) objects and to make sure the memory claimed by non-reachable objects can be reused is called the Mark and Sweep algorithm. It consists of two steps: 198 | 199 | 200 | JVM使用**标记-清除算法**(Mark and Sweep algorithm), 来跟踪所有的可达对象(即存活对象), 确保所有不可达对象(non-reachable objects)占用的内存都能被重用。其中包含两步: 201 | 202 | 203 | 204 | - **`Marking`** is walking through all reachable objects and keeping a ledger in native memory about all such objects 205 | 206 | 207 | - **`Sweeping`** is making sure the memory addresses occupied by non-reachable objects can be reused by the next allocations. 208 | 209 |
210 | 211 | - **`Marking`**(标记): 遍历所有的可达对象,并在本地内存(native)中分门别类记下。 212 | 213 | 214 | - **`Sweeping`**(清除): 这一步保证了,不可达对象所占用的内存, 在之后进行内存分配时可以重用。 215 | 216 | 217 | 218 | Different GC algorithms within the JVM, such as Parallel Scavenge, Parallel Mark+Copy or CMS, are implementing those phases slightly differently, but at conceptual level the process remains similar to the two steps described above. 219 | 220 | 221 | JVM中包含了多种GC算法, 如Parallel Scavenge(并行清除), Parallel Mark+Copy(并行标记+复制) 以及 CMS, 他们在实现上略有不同, 但理论上都采用了以上两个步骤。 222 | 223 | 224 | 225 | A crucially important thing about this approach is that the cycles are no longer leaked: 226 | 227 | 标记清除算法最重要的优势, 就是不再因为循环引用而导致内存泄露: 228 | 229 | 230 | 231 | 232 | ![](01_03_Java-GC-mark-and-sweep.png) 233 | 234 | 235 | 236 | The not-so-good thing is that the application threads need to be stopped for the collection to happen as you cannot really count references if they keep changing all the time. Such a situation when the application is temporarily stopped so that the JVM can indulge in housekeeping activities is called a **`Stop The World pause`**. They may happen for many reasons, but garbage collection is by far the most popular one. 237 | 238 | 239 | 而不好的地方在于, 垃圾收集过程中, 需要暂停应用程序的所有线程。假如不暂停,则对象间的引用关系会一直不停地发生变化, 那样就没法进行统计了。这种情况叫做 STW停顿(Stop The World pause, 全线暂停), 让应用程序暂时停止，让JVM进行内存清理工作。有很多原因会触发 STW停顿, 其中垃圾收集是最主要的因素。 240 | 241 | 242 | 243 | In this handbook, we will explain how Garbage Collection works in the JVM and how to get the best out of it. 244 | 245 | 在本手册中,我们将介绍JVM中垃圾收集的实现原理，以及如何高效地利用GC。 246 | 247 | 248 | 249 | 原文链接: [What Is Garbage Collection?](https://plumbr.eu/handbook/what-is-garbage-collection) 250 | 251 | 252 | 253 |
254 | 255 | 256 | -------------------------------------------------------------------------------- /01_What_Is_Garbage_Collection_CN.md: -------------------------------------------------------------------------------- 1 | > #### 说明: 2 | > 3 | > 在本文中, `Garbage Collection` 翻译为 “`垃圾收集`”, `garbage collector` 翻译为 “`垃圾收集器`”; 4 | > 5 | > 一般认为, **垃圾回收** 和 **垃圾收集** 是同义词。 6 | > 7 | > `Minor GC` 翻译为： **小型GC**; 而不是 次要GC 8 | > 9 | > `Major GC` 翻译为： **大型GC**; 而不是 主要GC 10 | > 11 | > 原因在于,大部分情况下, 发生在年轻代的 `Minor GC` 次数会很多,翻译为次要GC明显不对。 12 | > 13 | > `Full GC` 翻译为： **完全GC**; 为了清晰起见,一般直接译为 Full GC,读者明白即可; 其中大型GC和完全GC差不多, 这些术语出自官方的各种分析工具和垃圾收集日志。并不是很统一。 14 | 15 | 16 | # 1. 垃圾收集简介 17 | 18 | 顾名思义,垃圾收集(Garbage Collection)的意思就是 —— 找到垃圾并进行清理。但现有的垃圾收集实现却恰恰相反: **垃圾收集器跟踪所有正在使用的对象,并把其余部分当做垃圾**。记住这一点以后, 我们再深入讲解内存自动回收的原理，探究 JVM 中垃圾收集的具体实现, 。 19 | 20 | 我们不抠细节, 先从基础开始, 介绍垃圾收集的一般特征、核心概念以及实现算法。 21 | 22 | > **免责声明**: 本文主要讲解 Oracle Hotspot 和 OpenJDK 的行为。对于其他JVM, 如 jRockit 或者 IBM J9, 在某些方面可能会略有不同。 23 | 24 | 25 | ## 手动内存管理(Manual Memory Management) 26 | 27 | 当今的自动垃圾收集算法极为先进, 但我们先来看看什么是手动内存管理。在那个时候, 如果要存储共享数据, 必须显式地进行 内存分配(allocate)和内存释放(free)。如果忘记释放, 则对应的那块内存不能再次使用。内存一直被占着, 却不再使用，这种情况就称为**内存泄漏**(`memory leak`)。 28 | 29 | 以下是用C语言来手动管理内存的一个示例程序: 30 | 31 | 32 | int send_request() { 33 | size_t n = read_size(); 34 | int *elements = malloc(n * sizeof(int)); 35 | 36 | if(read_elements(n, elements) < n) { 37 | // elements not freed! 38 | return -1; 39 | } 40 | 41 | // … 42 | 43 | free(elements) 44 | return 0; 45 | } 46 | 47 | 48 | 可以看到,如果程序很长,或者结构比较复杂, 很可能就会忘记释放内存。内存泄漏曾经是个非常普遍的问题, 而且只能通过修复代码来解决。因此,业界迫切希望有一种更好的办法,来自动回收不再使用的内存,完全消除可能的人为错误。这种自动机制被称为 **垃圾收集**(`Garbage Collection`,简称GC)。 49 | 50 | ### 智能指针(Smart Pointers) 51 | 52 | 第一代自动垃圾收集算法, 使用的是**引用计数**(reference counting)。针对每个对象, 只需要记住被引用的次数, 当引用计数变为0时, 这个对象就可以被安全地回收(reclaimed)了。一个著名的示例是 C++ 的共享指针(shared pointers): 53 | 54 | int send_request() { 55 | size_t n = read_size(); 56 | shared_ptr> elements 57 | = make_shared>(); 58 | 59 | if(read_elements(n, elements) < n) { 60 | return -1; 61 | } 62 | 63 | return 0; 64 | } 65 | 66 | 67 | `shared_ptr` 被用来跟踪引用的数量。作为参数传递时这个数字加1, 在离开作用域时这个数字减1。当引用计数变为0时, `shared_ptr` 自动删除底层的 vector。需要向读者指出的是，这种方式在实际编程中并不常见, 此处仅用于演示。 68 | 69 | 70 | ## 自动内存管理(Automated Memory Management) 71 | 72 | 上面的C++代码中,我们要显式地声明什么时候需要进行内存管理。但不能让所有的对象都具备这种特征呢? 那样就太方便了, 开发者不再耗费脑细胞, 去考虑要在何处进行内存清理。运行时环境会自动算出哪些内存不再使用，并将其释放。换句话说, **自动进行收集垃圾**。第一款垃圾收集器是1959年为Lisp语言开发的, 此后 Lisp 的垃圾收集技术也一直处于业界领先水平。 73 | 74 | ### 引用计数(Reference Counting) 75 | 76 | 刚刚演示的C++共享指针方式, 可以应用到所有对象。许多语言都采用这种方法, 包括 Perl、Python 和 PHP 等。下图很好地展示了这种方式: 77 | 78 | ![](01_01_Java-GC-counting-references1.png) 79 | 80 | 图中绿色的云(GC ROOTS) 表示程序正在使用的对象。从技术上讲, 这些可能是当前正在执行的方法中的局部变量，或者是静态变量一类。在某些编程语言中,可能叫法不太一样,这里不必抠名词。 81 | 82 | 蓝色的圆圈表示可以引用到的对象, 里面的数字就是引用计数。然后, 灰色的圆圈是各个作用域都不再引用的对象。灰色的对象被认为是垃圾, 随时会被垃圾收集器清理。 83 | 84 | 看起来很棒, 是吧! 但这种方式有个大坑, 很容易被**循环引用**(`detached cycle`) 给搞死。任何作用域中都没有引用指向这些对象，但由于循环引用, 导致引用计数一直大于零。如下图所示: 85 | 86 | ![](01_02_Java-GC-cyclical-dependencies.png) 87 | 88 | 看到了吗? 红色的对象实际上属于垃圾。但由于引用计数的局限, 所以存在内存泄漏。 89 | 90 | 当然也有一些办法来应对这种情况, 例如 “**弱引用**”(‘weak’ references), 或者使用另外的算法来排查循环引用等。前面提到的 Perl、Python 和PHP 等语言, 都使用了某些方式来解决循环引用问题, 但本文不对其进行讨论。下面介绍JVM中使用的垃圾收集方法。 91 | 92 | ### 标记-清除(Mark and Sweep) 93 | 94 | 首先, JVM 明确定义了什么是对象的可达性(reachability)。我们前面所说的绿色云这种只能算是模糊的定义, JVM 中有一类很明确很具体的对象, 称为 **垃圾收集根元素**(`Garbage Collection Roots`)，包括: 95 | 96 | - 局部变量(Local variables) 97 | - 活动线程(Active threads) 98 | - 静态域(Static fields) 99 | - JNI引用(JNI references) 100 | - 其他对象(稍后介绍 ...) 101 | 102 | JVM使用**标记-清除算法**(Mark and Sweep algorithm), 来跟踪所有的可达对象(即存活对象), 确保所有不可达对象(non-reachable objects)占用的内存都能被重用。其中包含两步: 103 | 104 | - **`Marking`**(标记): 遍历所有的可达对象,并在本地内存(native)中分门别类记下。 105 | 106 | - **`Sweeping`**(清除): 这一步保证了,不可达对象所占用的内存, 在之后进行内存分配时可以重用。 107 | 108 | JVM中包含了多种GC算法, 如Parallel Scavenge(并行清除), Parallel Mark+Copy(并行标记+复制) 以及 CMS, 他们在实现上略有不同, 但理论上都采用了以上两个步骤。 109 | 110 | 标记清除算法最重要的优势, 就是不再因为循环引用而导致内存泄露: 111 | 112 | ![](01_03_Java-GC-mark-and-sweep.png) 113 | 114 | 而不好的地方在于, 垃圾收集过程中, 需要暂停应用程序的所有线程。假如不暂停,则对象间的引用关系会一直不停地发生变化, 那样就没法进行统计了。这种情况叫做 **STW停顿**(**`Stop The World pause`**, 全线暂停), 让应用程序暂时停止，让JVM进行内存清理工作。有很多原因会触发 STW停顿, 其中垃圾收集是最主要的因素。 115 | 116 | 在本手册中,我们将介绍JVM中垃圾收集的实现原理，以及如何高效地利用GC。 117 | 118 | 119 | 原文链接: [What Is Garbage Collection?](https://plumbr.eu/handbook/what-is-garbage-collection) 120 | 121 | 翻译人员: [铁锚 http://blog.csdn.net/renfufei](http://blog.csdn.net/renfufei) 122 | 123 | 翻译时间: 2015年10月26日 124 | -------------------------------------------------------------------------------- /02_01_fragmented-vs-compacted-heap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/02_01_fragmented-vs-compacted-heap.png -------------------------------------------------------------------------------- /02_02_object-age-based-on-GC-gen-hypothesis.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/02_02_object-age-based-on-GC-gen-hypothesis.png -------------------------------------------------------------------------------- /02_03_java-heap-eden-survivor-old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/02_03_java-heap-eden-survivor-old.png -------------------------------------------------------------------------------- /02_04_TLAB-in-Eden-memory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/02_04_TLAB-in-Eden-memory.png -------------------------------------------------------------------------------- /02_05_how-java-gc-works.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/02_05_how-java-gc-works.png -------------------------------------------------------------------------------- /02_Garbage_Collection_in_Java.md: -------------------------------------------------------------------------------- 1 | # 2. Java中的垃圾收集 2 | 3 | 4 | The introduction to Mark and Sweep Garbage Collection is a mostly theoretical one. When things come to practice, numerous adjustments need to be done to accommodate for real-world scenarios and needs. For a simple example, let us take a look at what sorts of bookkeeping the JVM needs to do so that we can safely continue allocating objects. 5 | 6 | 7 | **标记-清除**(Mark and Sweep)是最经典的垃圾收集算法。将理论用于生产实践时, 会有很多需要优化调整的地方, 以适应具体环境。下面通过一个简单的例子, 让我们一步步记录下来, 看看如何才能保证JVM能安全持续地分配对象。 8 | 9 | 10 | 11 | ## Fragmenting and Compacting 12 | 13 | ## 碎片整理(Fragmenting and Compacting) 14 | 15 | 16 | 17 | Whenever sweeping takes place, the JVM has to make sure the areas filled with unreachable objects can be reused. This can (and eventually will) lead to memory fragmentation which, similarly to disk fragmentation, leads to two problems: 18 | 19 | 20 | 每次执行清除(sweeping), JVM 都必须保证不可达对象占用的内存能被回收重用。但这(最终)有可能会产生内存碎片(类似于磁盘碎片), 进而引发两个问题: 21 | 22 | 23 | - Write operations become more time-consuming as finding the next free block of sufficient size is no longer a trivial operation. 24 | 25 | - When creating new objects, JVM is allocating memory in contiguous blocks. So if fragmentation escalates to a point where no individual free fragment is large enough to accommodate the newly created object, an allocation error occurs. 26 | 27 | - 写入操作越来越耗时, 因为寻找一块足够大的空闲内存会变得非常麻烦。 28 | 29 | - 在创建新对象时, JVM在连续的块中分配内存。如果碎片问题很严重, 直至没有空闲片段能存放下新创建的对象,就会发生内存分配错误(allocation error)。 30 | 31 | 32 | 33 | To avoid such problems, the JVM is making sure the fragmenting does not get out of hand. So instead of just marking and sweeping, a ‘memory defrag’ process also happens during garbage collection. This process relocates all the reachable objects next to each other, eliminating (or reducing) the fragmentation. Here is an illustration of that: 34 | 35 | 36 | 要避免这类问题,JVM 必须确保碎片问题不失控。因此在垃圾收集过程中, 不仅仅是标记和清除, 还需要执行 “内存碎片整理” 过程。这个过程让所有可达对象(reachable objects)依次排列, 以消除(或减少)碎片。示意图如下所示: 37 | 38 | 39 | ![](02_01_fragmented-vs-compacted-heap.png) 40 | 41 | 42 | > **说明**: 43 | > 44 | > JVM中的引用是一个抽象的概念,如果GC移动某个对象, 就会修改(栈和堆中)所有指向该对象的引用。 45 | > 46 | > 移动/拷贝/提升/压缩 是一个 STW 的过程,所以修改对象引用是一个安全的行为。但要更新所有的引用,对某些程序可能性能低下。 47 | 48 | 49 | 50 | 51 | ## Generational Hypothesis 52 | 53 | ## 分代假设(Generational Hypothesis) 54 | 55 | 56 | As we have mentioned before, doing a garbage collection entails stopping the application completely. It is also quite obvious that the more objects there are the longer it takes to collect all the garbage. But what if we would have a possibility to work with smaller memory regions? Investigating the possibilities, a group of researchers has observed that most allocations inside applications fall into two categories: 57 | 58 | 我们前面提到过,执行垃圾收集需要停止整个应用。很明显,对象越多则收集所有垃圾消耗的时间就越长。但可不可以只处理一个较小的内存区域呢? 为了探究这种可能性,研究人员发现,程序中的大多数可回收的内存可归为两类: 59 | 60 | 61 | - Most of the objects become unused quickly 62 | 63 | - The ones that do not usually survive for a (very) long time 64 | 65 | 66 | - 大部分对象很快就不再使用 67 | 68 | - 还有一部分不会立即无用,但也不会持续(太)长时间 69 | 70 | 71 | 72 | These observations come together in the Weak Generational Hypothesis. Based on this hypothesis, the memory inside the VM is divided into what is called the **Young Generation** and the **Old Generation**. The latter is sometimes also called **Tenured**. 73 | 74 | 这些观测形成了 **弱代假设**(Weak Generational Hypothesis)。基于这一假设, VM中的内存被分为**年轻代**(Young Generation)和**老年代**(Old Generation)。老年代有时候也称为 **年老区**(Tenured)。 75 | 76 | ![](02_02_object-age-based-on-GC-gen-hypothesis.png) 77 | 78 | 79 | Having such separate and individually cleanable areas allows for a multitude of different algorithms that have come a long way in improving the performance of the GC. 80 | 81 | 拆分为这样两个可清理的单独区域，允许采用不同的算法来大幅提高GC的性能。 82 | 83 | 84 | This is not to say there are no issues with such an approach. For one, objects from different generations may in fact have references to each other that also count as ‘de facto’ GC roots when collecting a generation. 85 | 86 | 这种方法也不是没有问题。例如，在不同分代中的对象可能会互相引用, 在收集某一个分代时就会成为 "事实上的" GC root。 87 | 88 | 89 | But most importantly, the generational hypothesis may in fact not hold for some applications. Since the GC algorithms are optimized for objects which either ‘die young’ or ‘are likely to live forever’, the JVM behaves rather poorly with objects with ‘medium’ life expectancy. 90 | 91 | 当然,要着重强调的是,分代假设并不适用于所有程序。因为GC算法专门针对“要么死得快”，“否则活得长” 这类特征的对象来进行优化, JVM对收集那种存活时间半长不长的对象就显得非常尴尬了。 92 | 93 | ## Memory Pools 94 | 95 | ## 内存池(Memory Pools) 96 | 97 | 98 | The following division of memory pools within the heap should be familiar. What is not so commonly understood is how Garbage Collection performs its duties within the different memory pools. Notice that in different GC algorithms some implementation details might vary but, again, the concepts in this chapter remain effectively the same. 99 | 100 | 堆内存中的内存池划分也是类似的。不太容易理解的地方在于各个内存池中的垃圾收集是如何运行的。请注意,不同的GC算法在实现细节上可能会有所不同,但和本章所介绍的相关概念都是一致的。 101 | 102 | 103 | ![](02_03_java-heap-eden-survivor-old.png) 104 | 105 | 106 | 107 | ### Eden 108 | 109 | ### 新生代(Eden,伊甸园) 110 | 111 | 112 | Eden is the region in memory where the objects are typically allocated when they are created. As there are typically multiple threads creating a lot of objects simultaneously, Eden is further divided into one or more **Thread Local Allocation Buffer** (TLAB for short) residing in the Eden space. These buffers allow the JVM to allocate most objects within one thread directly in the corresponding TLAB, avoiding the expensive synchronization with other threads. 113 | 114 | Eden 是内存中的一个区域, 用来分配新创建的对象。通常会有多个线程同时创建多个对象, 所以 Eden 区被划分为多个 **线程本地分配缓冲区**(Thread Local Allocation Buffer, 简称TLAB)。通过这种缓冲区划分,大部分对象直接由JVM 在对应线程的TLAB中分配, 避免与其他线程的同步操作。 115 | 116 | 117 | 118 | When allocation inside a TLAB is not possible (typically because there’s not enough room there), the allocation moves on to a shared Eden space. If there’s not enough room in there either, a garbage collection process in Young Generation is triggered to free up more space. If the garbage collection also does not result in sufficient free memory inside Eden, then the object is allocated in the Old Generation. 119 | 120 | 如果 TLAB 中没有足够的内存空间, 就会在共享Eden区(shared Eden space)之中分配。如果共享Eden区也没有足够的空间, 就会触发一次 年轻代GC 来释放内存空间。如果GC之后 Eden 区依然没有足够的空闲内存区域, 则对象就会被分配到老年代空间(Old Generation)。 121 | 122 | 123 | 124 | When Eden is being collected, GC walks all the reachable objects from the roots and marks them as alive. 125 | 126 | 当 Eden 区进行垃圾收集时, GC将所有从 root 可达的对象过一遍, 并标记为存活对象。 127 | 128 | 129 | 130 | We have previously noted that objects can have cross-generational links so a straightforward approach would have to check all the references from other generations to Eden. Doing so would unfortunately defeat the whole point of having generations in the first place. The JVM has a trick up its sleeve: card-marking. Essentially, the JVM just marks the rough location of ‘dirty’ objects in Eden that may have links to them from the Old Generation. You can read more on that in Nitsan’s [blog entry](http://psy-lob-saw.blogspot.com/2014/10/the-jvm-write-barrier-card-marking.html). 131 | 132 | 我们曾指出,对象间可能会有跨代的引用, 所以需要一种方法来标记从其他分代中指向Eden的所有引用。这样做又会遭遇各个分代之间一遍又一遍的引用。JVM在实现时采用了一些绝招: 卡片标记(card-marking)。从本质上讲,JVM只需要记住Eden区中 “脏”对象的粗略位置, 可能有老年代的对象引用指向这部分区间。更多细节请参考: [Nitsan 的博客](http://psy-lob-saw.blogspot.com/2014/10/the-jvm-write-barrier-card-marking.html) 。 133 | 134 | 135 | ![](02_04_TLAB-in-Eden-memory.png) 136 | 137 | 138 | 139 | After the marking phase is completed, all the live objects in Eden are copied to one of the Survivor spaces. The whole Eden is now considered to be empty and can be reused to allocate more objects. Such an approach is called “**Mark and Copy**”: the live objects are marked, and then copied (not moved) to a survivor space. 140 | 141 | 标记阶段完成后, Eden中所有存活的对象都会被复制到存活区(Survivor spaces)里面。整个Eden区就可以被认为是空的, 然后就能用来分配新对象。这种方法称为 “**标记-复制**”(Mark and Copy): 存活的对象被标记, 然后复制到一个存活区(注意,是复制,而不是移动)。 142 | 143 | 144 | 145 | ### Survivor Spaces 146 | 147 | ### 存活区(Survivor Spaces) 148 | 149 | 150 | Next to the Eden space reside two **Survivor** spaces called from and to. It is important to notice that one of the two Survivor spaces is always empty. 151 | 152 | Eden 区的旁边是两个**存活区**, 称为 `from 空间`和 `to 空间`。需要着重强调的的是, 任意时刻总有一个存活区是空的(empty)。 153 | 154 | 155 | 156 | The empty Survivor space will start having residents next time the Young generation gets collected. All of the live objects from the whole of the Young generation (that includes both the Eden space and the non-empty ‘from’ Survivor space) are copied to the ‘to’ survivor space. After this process has completed, ‘to’ now contains objects and ‘from’ does not. Their roles are switched at this time. 157 | 158 | 空的那个存活区用于在下一次年轻代GC时存放收集的对象。年轻代中所有的存活对象(包括Edenq区和非空的那个 "from" 存活区)都会被复制到 ”to“ 存活区。GC过程完成后, ”to“ 区有对象,而 'from' 区里没有对象。两者的角色进行正好切换 。 159 | 160 | 161 | ![](02_05_how-java-gc-works.png) 162 | 163 | 164 | 165 | This process of copying the live objects between the two Survivor spaces is repeated several times until some objects are considered to have matured and are ‘old enough’. Remember that, based on the generational hypothesis, objects which have survived for some time are expected to continue to be used for very long time. 166 | 167 | 存活的对象会在两个存活区之间复制多次, 直到某些对象的存活 时间达到一定的阀值。分代理论假设, 存活超过一定时间的对象很可能会继续存活更长时间。 168 | 169 | 170 | Such ‘tenured’ objects can thus be **promoted** to the Old Generation. When this happens, objects are not moved from one survivor space to another but instead to the Old space, where they will reside until they become unreachable. 171 | 172 | 这类“ 年老” 的对象因此被**提升**(promoted )到老年代。提升的时候， 存活区的对象不再是复制到另一个存活区,而是迁移到老年代, 并在老年代一直驻留, 直到变为不可达对象。 173 | 174 | 175 | To determine whether the object is ‘old enough’ to be considered ready for propagation to Old space, GC tracks the number of collections a particular object has survived. After each generation of objects finishes with a GC, those still alive have their age incremented. Whenever the age exceeds a certain **tenuring threshold** the object will be promoted to Old space. 176 | 177 | 为了确定一个对象是否“足够老”, 可以被提升(Promotion)到老年代，GC模块跟踪记录每个存活区对象存活的次数。每次分代GC完成后,存活对象的年龄就会增长。当年龄超过**提升阈值**(tenuring threshold), 就会被提升到老年代区域。 178 | 179 | 180 | The actual tenuring threshold is dynamically adjusted by the JVM, but specifying `-XX:+MaxTenuringThreshold` sets an upper limit on it. Setting `-XX:+MaxTenuringThreshold=0` results in immediate promotion without copying it between Survivor spaces. By default, this threshold on modern JVMs is set to 15 GC cycles. This is also the maximum value in HotSpot. 181 | 182 | 具体的提升阈值由JVM动态调整,但也可以用参数 `-XX:+MaxTenuringThreshold` 来指定上限。如果设置 `-XX:+MaxTenuringThreshold=0` , 则GC时存活对象不在存活区之间复制，直接提升到老年代。现代 JVM 中这个阈值默认设置为**15**个 GC周期。这也是HotSpot中的最大值。 183 | 184 | 185 | Promotion may also happen prematurely if the size of the Survivor space is not enough to hold all of the live objects in the Young generation. 186 | 187 | 如果存活区空间不够存放年轻代中的存活对象，提升(Promotion)也可能更早地进行。 188 | 189 | ### Old Generation 190 | 191 | ### 老年代(Old Generation) 192 | 193 | 194 | 195 | 196 | The implementation for the Old Generation memory space is much more complex. Old Generation is usually significantly larger and is occupied by objects that are less likely to be garbage. 197 | 198 | 老年代的GC实现要复杂得多。老年代内存空间通常会更大，里面的对象是垃圾的概率也更小。 199 | 200 | 201 | 202 | GC in the Old Generation happens less frequently than in the Young Generation. Also, since most objects are expected to be alive in the Old Generation, there is no Mark and Copy happening. Instead, the objects are moved around to minimize fragmentation. The algorithms cleaning the Old space are generally built on different foundations. In principle, the steps taken go through the following: 203 | 204 | 老年代GC发生的频率比年轻代小很多。同时, 因为预期老年代中的对象大部分是存活的, 所以不再使用标记和复制(Mark and Copy)算法。而是采用移动对象的方式来实现最小化内存碎片。老年代空间的清理算法通常是建立在不同的基础上的。原则上,会执行以下这些步骤: 205 | 206 | 207 | 208 | - Mark reachable objects by setting the marked bit next to all objects accessible through GC roots 209 | 210 | - Delete all unreachable objects 211 | 212 | - Compact the content of old space by copying the live objects contiguously to the beginning of the Old space 213 | 214 | - 通过标志位(marked bit),标记所有通过 GC roots 可达的对象. 215 | 216 | - 删除所有不可达对象 217 | 218 | - 整理老年代空间中的内容，方法是将所有的存活对象复制,从老年代空间开始的地方,依次存放。 219 | 220 | 221 | As you can see from the description, GC in Old Generation has to deal with explicit compacting to avoid excessive fragmentation. 222 | 223 | 通过上面的描述可知, 老年代GC必须明确地进行整理,以避免内存碎片过多。 224 | 225 | ### PermGen 226 | 227 | ### 永久代(PermGen) 228 | 229 | 230 | 231 | Prior to Java 8 there existed a special space called the ‘Permanent Generation’. This is where the metadata such as classes would go. Also, some additional things like internalized strings were kept in Permgen. It actually used to create a lot of trouble to Java developers, since it is quite hard to predict how much space all of that would require. Result of these failed predictions took the form of [`java.lang.OutOfMemoryError: Permgen space`](https://plumbr.eu/outofmemoryerror/permgen-space). Unless the cause of such OutOfMemoryError was an actual memory leak, the way to fix this problem was to simply increase the permgen size similar to the following example setting the maximum allowed permgen size to 256 MB: 232 | 233 | 在Java 8 之前有一个特殊的空间,称为“永久代”(Permanent Generation)。这是存储元数据(metadata)的地方,比如 class 信息等。此外,这个区域中也保存有其他的数据和信息, 包括 内部化的字符串(internalized strings)等等。实际上这给Java开发者造成了很多麻烦,因为很难去计算这块区域到底需要占用多少内存空间。预测失败导致的结果就是产生 [`java.lang.OutOfMemoryError: Permgen space`](https://plumbr.eu/outofmemoryerror/permgen-space) 这种形式的错误。除非 ·OutOfMemoryError· 确实是内存泄漏导致的,否则就只能增加 permgen 的大小，例如下面的示例，就是设置 permgen 最大空间为 256 MB: 234 | 235 | 236 | java -XX:MaxPermSize=256m com.mycompany.MyApplication 237 | 238 | 239 | ### Metaspace 240 | 241 | ### 元数据区(Metaspace) 242 | 243 | 244 | 245 | As predicting the need for metadata was a complex and inconvenient exercise, the Permanent Generation was removed in Java 8 in favor of the Metaspace. From this point on, most of the miscellaneous things were moved to regular Java heap. 246 | 247 | 既然估算元数据所需空间那么复杂, Java 8直接删除了永久代(Permanent Generation)，改用 Metaspace。从此以后, Java 中很多杂七杂八的东西都放置到普通的堆内存里。 248 | 249 | 250 | The class definitions, however, are now loaded into something called Metaspace. It is located in the native memory and does not interfere with the regular heap objects. By default, Metaspace size is only limited by the amount of native memory available to the Java process. This saves developers from a situation when adding just one more class to the application results in the [java.lang.OutOfMemoryError: Permgen space](https://plumbr.eu/outofmemoryerror/permgen-space). Notice that having such seemingly unlimited space does not ship without costs – letting the Metaspace to grow uncontrollably you can introduce heavy swapping and/or reach native allocation failures instead. 251 | 252 | 当然，像类定义(class definitions)之类的信息会被加载到 Metaspace 中。元数据区位于本地内存(native memory),不再影响到普通的Java对象。默认情况下, Metaspace的大小只受限于 Java进程可用的本地内存。这样程序就不再因为多加载了几个类/JAR包就导致 [`java.lang.OutOfMemoryError: Permgen space. `](https://plumbr.eu/outofmemoryerror/permgen-space) 。注意, 这种不受限制的空间也不是没有代价的 —— 如果 Metaspace 失控, 则可能会导致很严重的内存交换(swapping), 或者导致本地内存分配失败。 253 | 254 | 255 | In case you still wish to protect yourself for such occasions you can limit the growth of Metaspace similar to following, limiting Metaspace size to 256 MB: 256 | 257 | 如果需要避免这种最坏情况，那么可以通过下面这样的方式来限制 Metaspace 的大小, 如 256 MB: 258 | 259 | 260 | java -XX:MaxMetaspaceSize=256m com.mycompany.MyApplication 261 | 262 | 263 | ## Minor GC vs Major GC vs Full GC 264 | 265 | 266 | 267 | The Garbage Collection events cleaning out different parts inside heap memory are often called Minor, Major and Full GC events. In this section we cover the differences between these events. Along the way we can hopefully see that this distinction is actually not too relevant. 268 | 269 | 垃圾收集事件(Garbage Collection events)通常分为: 小型GC(Minor GC) - 大型GC(Major GC) - 和完全GC(Full GC) 。本节介绍这些事件及其区别。然后你会发现这些区别也不是特别清晰。 270 | 271 | 272 | What typically is relevant is whether the application meets its SLAs, and to see that you monitor your application for latency or throughput. And only then are GC events linked to the results. What is important about these events is whether they stopped the application and how long it took. 273 | 274 | 最重要的是,应用程序是否满足 服务级别协议(Service Level Agreement, SLA), 并通过监控程序查看响应延迟和吞吐量。也只有那时候才能看到GC事件相关的结果。重要的是这些事件是否停止整个程序,以及持续多长时间。 275 | 276 | 277 | But as the terms Minor, Major and Full GC are widely used and without a proper definition, let us look into the topic in a bit more detail. 278 | 279 | 虽然 Minor, Major 和 Full GC 这些术语被广泛应用, 但并没有标准的定义, 我们还是来深入了解一下具体的细节吧。 280 | 281 | ### Minor GC 282 | 283 | ### 小型GC(Minor GC) 284 | 285 | 286 | Collecting garbage from the Young space is called **Minor GC**. This definition is both clear and uniformly understood. But there are still some interesting takeaways you should be aware of when dealing with Minor Garbage Collection events: 287 | 288 | 年轻代内存的垃圾收集事件称为**小型GC**。这个定义既清晰又得到广泛共识。对于小型GC事件,有一些有趣的事情你应该了解一下: 289 | 290 | 1. Minor GC is always triggered when the JVM is unable to allocate space for a new object, e.g. Eden is getting full. So the higher the allocation rate, the more frequently Minor GC occurs. 291 | 292 | 293 | 1. 当JVM无法为新对象分配内存空间时总会触发 Minor GC,比如 Eden 区占满时。所以(新对象)分配频率越高, Minor GC 的频率就越高。 294 | 295 | 296 | 1. During a Minor GC event, Tenured Generation is effectively ignored. References from Tenured Generation to Young Generation are considered to be GC roots. References from Young Generation to Tenured Generation are simply ignored during the mark phase. 297 | 298 | 299 | 1. Minor GC 事件实际上忽略了老年代。从老年代指向年轻代的引用都被认为是GC Root。而从年轻代指向老年代的引用在标记阶段全部被忽略。 300 | 301 | 302 | 1. Against common belief, Minor GC does trigger stop-the-world pauses, suspending the application threads. For most applications, the length of the pauses is negligible latency-wise if most of the objects in the Eden can be considered garbage and are never copied to Survivor/Old spaces. If the opposite is true and most of the newborn objects are not eligible for collection, Minor GC pauses start taking considerably more time. 303 | 304 | 305 | 1. 与一般的认识相反, Minor GC 每次都会引起全线停顿(stop-the-world ), 暂停所有的应用线程。对大多数程序而言,暂停时长基本上是可以忽略不计的, 因为 Eden 区的对象基本上都是垃圾, 也不怎么复制到存活区/老年代。如果情况不是这样, 大部分新创建的对象不能被垃圾回收清理掉, 则 Minor GC的停顿就会持续更长的时间。 306 | 307 | 308 | So defining Minor GC is easy – **Minor GC cleans the Young Generation**. 309 | 310 | 所以 Minor GC 的定义很简单 —— **Minor GC 清理的就是年轻代**。 311 | 312 | ### Major GC vs Full GC 313 | 314 | 315 | 316 | It should be noted that there are no formal definitions for those terms – neither in the JVM specification nor in the Garbage Collection research papers. But on the first glance, building these definitions on top of what we know to be true about Minor GC cleaning Young space should be simple: 317 | 318 | 值得一提的是, 这些术语并没有正式的定义 —— 无论是在JVM规范还是在GC相关论文中。 319 | 320 | 我们知道, Minor GC 清理的是年轻代空间(Young space)，相应的,其他定义也很简单: 321 | 322 | - **Major GC** is cleaning the Old space. 323 | 324 | 325 | - **Major GC**(大型GC) 清理的是老年代空间(Old space)。 326 | 327 | 328 | 329 | - **Full GC** is cleaning the entire Heap – both Young and Old spaces. 330 | 331 | 332 | - **Full GC**(完全GC)清理的是整个堆, 包括年轻代和老年代空间。 333 | 334 | 335 | Unfortunately it is a bit more complex and confusing. To start with – many Major GCs are triggered by Minor GCs, so separating the two is impossible in many cases. On the other hand – modern garbage collection algorithms like G1 perform partial garbage cleaning so, again, using the term ‘cleaning’ is only partially correct. 336 | 337 | 杯具的是更复杂的情况出现了。很多 Major GC 是由 Minor GC 触发的, 所以很多情况下这两者是不可分离的。另一方面, 像G1这样的垃圾收集算法执行的是部分区域垃圾回收, 所以，额，使用术语“cleaning”并不是非常准确。 338 | 339 | 340 | 341 | This leads us to the point where **instead of worrying about whether the GC is called Major or Full GC, you should focus on finding out whether the GC at hand stopped all the application threads or was able to progress concurrently with the application threads**. 342 | 343 | 这也让我们认识到,**不应该去操心是叫 Major GC 呢还是叫 Full GC, 我们应该关注的是: 某次GC事件 是否停止所有线程,或者是与其他线程并发执行**。 344 | 345 | 346 | This confusion is even built right into the JVM standard tools. What I mean by that is best explained via an example. Let us compare the output of two different tools tracing the GC on a JVM running with Concurrent Mark and Sweep collector (`-XX:+UseConcMarkSweepGC`) 347 | 348 | 349 | 这些混淆甚至根植于标准的JVM工具中。我的意思可以通过实例来说明。让我们来对比同一JVM中两款工具的GC信息输出吧。这个JVM使用的是 **并发标记和清除收集器**（Concurrent Mark and Sweep collector，`-XX:+UseConcMarkSweepGC`). 350 | 351 | 352 | 353 | First attempt is to get the insight via the [jstat](http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html) output: 354 | 355 | 首先我们来看 [`jstat`](http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html) 的输出: 356 | 357 | 358 | > `jstat -gc -t 4235 1s` 359 | 360 | 361 | 362 | Time S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 363 | 5.7 34048.0 34048.0 0.0 34048.0 272640.0 194699.7 1756416.0 181419.9 18304.0 17865.1 2688.0 2497.6 3 0.275 0 0.000 0.275 364 | 6.7 34048.0 34048.0 34048.0 0.0 272640.0 247555.4 1756416.0 263447.9 18816.0 18123.3 2688.0 2523.1 4 0.359 0 0.000 0.359 365 | 7.7 34048.0 34048.0 0.0 34048.0 272640.0 257729.3 1756416.0 345109.8 19072.0 18396.6 2688.0 2550.3 5 0.451 0 0.000 0.451 366 | 8.7 34048.0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0 444982.5 19456.0 18681.3 2816.0 2575.8 7 0.550 0 0.000 0.550 367 | 9.7 34048.0 34048.0 34046.7 0.0 272640.0 16777.0 1756416.0 587906.3 20096.0 19235.1 2944.0 2631.8 8 0.720 0 0.000 0.720 368 | 10.7 34048.0 34048.0 0.0 34046.2 272640.0 80171.6 1756416.0 664913.4 20352.0 19495.9 2944.0 2657.4 9 0.810 0 0.000 0.810 369 | 11.7 34048.0 34048.0 34048.0 0.0 272640.0 129480.8 1756416.0 745100.2 20608.0 19704.5 2944.0 2678.4 10 0.896 0 0.000 0.896 370 | 12.7 34048.0 34048.0 0.0 34046.6 272640.0 164070.7 1756416.0 822073.7 20992.0 19937.1 3072.0 2702.8 11 0.978 0 0.000 0.978 371 | 13.7 34048.0 34048.0 34048.0 0.0 272640.0 211949.9 1756416.0 897364.4 21248.0 20179.6 3072.0 2728.1 12 1.087 1 0.004 1.091 372 | 14.7 34048.0 34048.0 0.0 34047.1 272640.0 245801.5 1756416.0 597362.6 21504.0 20390.6 3072.0 2750.3 13 1.183 2 0.050 1.233 373 | 15.7 34048.0 34048.0 0.0 34048.0 272640.0 21474.1 1756416.0 757347.0 22012.0 20792.0 3200.0 2791.0 15 1.336 2 0.050 1.386 374 | 16.7 34048.0 34048.0 34047.0 0.0 272640.0 48378.0 1756416.0 838594.4 22268.0 21003.5 3200.0 2813.2 16 1.433 2 0.050 1.484 375 | 376 | 377 | This snippet is extracted from the first 17 seconds after the JVM was launched. Based on this information we could conclude that after 12 Minor GC runs two Full GC runs were performed, spanning **50ms** in total. You would get the same confirmation via GUI-based tools, such as the [jconsole](http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html) or [jvisualvm](http://download.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html). 378 | 379 | 此片段截取自JVM启动后的前17秒。根据这些信息可以得知: 有2次Full GC在12次Minor GC(YGC)之后触发执行, 总计耗时 **50ms**。当然,也可以通过具备图形界面的工具得出同样的信息, 比如 [jconsole](http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html) 或者 [jvisualvm](http://download.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html) (或者最新的 jmc)。 380 | 381 | 382 | Before nodding at this conclusion, let’s look at the output of the garbage collection logs gathered from the same JVM launch. Apparently -XX:+PrintGCDetails tells us a different and a more detailed story: 383 | 384 | 在下结论之前, 让我们看看此JVM进程的GC日志。显然需要配置 `-XX:+PrintGCDetails` 参数,GC日志的内容更详细,结果也有一些不同: 385 | 386 | 387 | > `java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer` 388 | 389 | 3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K->34048K(306688K), 0.0844702 secs] 272640K->69574K(2063104K), 0.0845560 secs] [Times: user=0.23 sys=0.03, real=0.09 secs] 390 | 4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K->34048K(306688K), 0.1013723 secs] 342214K->136584K(2063104K), 0.1014307 secs] [Times: user=0.25 sys=0.05, real=0.10 secs] 391 | ... cut for brevity ... 392 | 393 | 11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K->34048K(306688K), 0.0857219 secs] 971599K->779148K(2063104K), 0.0857875 secs] [Times: user=0.26 sys=0.04, real=0.09 secs] 394 | 12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K->34046K(306688K), 0.0821774 secs] 1051788K->856120K(2063104K), 0.0822400 secs] [Times: user=0.25 sys=0.03, real=0.08 secs] 395 | 12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K->34048K(306688K), 0.1086667 secs] 1128760K->931412K(2063104K), 0.1087416 secs] [Times: user=0.24 sys=0.04, real=0.11 secs] 396 | 13.098: [GC (CMS Initial Mark) [1 CMS-initial-mark: 897364K(1756416K)] 936667K(2063104K), 0.0041705 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 397 | 13.102: [CMS-concurrent-mark-start] 398 | 13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01, real=0.24 secs] 399 | 13.341: [CMS-concurrent-preclean-start] 400 | 13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 401 | 13.350: [CMS-concurrent-abortable-preclean-start] 402 | 13.878: [GC (Allocation Failure) 13.878: [ParNew: 306688K->34047K(306688K), 0.0960456 secs] 1204052K->1010638K(2063104K), 0.0961542 secs] [Times: user=0.29 sys=0.04, real=0.09 secs] 403 | 14.366: [CMS-concurrent-abortable-preclean: 0.917/1.016 secs] [Times: user=2.22 sys=0.07, real=1.01 secs] 404 | 14.366: [GC (CMS Final Remark) [YG occupancy: 182593 K (306688 K)]14.366: [Rescan (parallel) , 0.0291598 secs]14.395: [weak refs processing, 0.0000232 secs]14.395: [class unloading, 0.0117661 secs]14.407: [scrub symbol table, 0.0015323 secs]14.409: [scrub string table, 0.0003221 secs][1 CMS-remark: 976591K(1756416K)] 1159184K(2063104K), 0.0462010 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 405 | 14.412: [CMS-concurrent-sweep-start] 406 | 14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00, real=0.22 secs] 407 | 14.633: [CMS-concurrent-reset-start] 408 | 14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 409 | 410 | 411 | 412 | Based on this information we can see that after 12 Minor GC runs ‘something different’ indeed started happening. But instead of two Full GC runs, this ‘different thing’ was in reality just a single GC running in Old generation and consisting of different phases: 413 | 414 | 通过GC日志可以看到, 在12 次 Minor GC之后发生了一些 "不同的事情"。并不是两个 Full GC, 而是在老年代执行了一次 GC, 分为多个阶段执行: 415 | 416 | 417 | 418 | - Initial Mark phase, spanning for 0.0041705 seconds or approximately 4ms. This phase is a stop-the-world event stopping all application threads for initial marking. 419 | 420 | 421 | - 初始标记阶段(Initial Mark phase),耗时 0.0041705秒(约4ms)。此阶段是全线停顿(STW)事件,暂停所有应用线程,以便执行初始标记。 422 | 423 | 424 | - Markup and Preclean phases. were executed concurrently with the application threads. 425 | 426 | 427 | - 标记和预清理阶段(Markup and Preclean phase)。和应用线程并发执行。 428 | 429 | 430 | - Final Remark phase, spanning for 0.0462010 seconds or approximately 46ms. This phase is again stop-the-world event. 431 | 432 | 433 | - 最终标记阶段(Final Remark phase), 耗时 0.0462010秒(约46ms)。此阶段也是全线停顿(STW)事件。 434 | 435 | 436 | 437 | - Sweep operation was executed concurrently, without stopping the application threads. 438 | 439 | 440 | - 清除操作(Sweep)是并发执行的, 不需要暂停应用线程。 441 | 442 | 443 | So what we see from the actual garbage collection logs is that, instead of two Full GC operations, just one Major GC cleaning Old space was actually executed. 444 | 445 | 所以从实际的GC日志可以看到, 并不是执行了两次 Full GC操作, 而是只执行了一次清理老年代空间的 Major GC 。 446 | 447 | 448 | If you were after latency then the data revealed by `jstat` would have led you towards correct decisions. It correctly listed the two stop-the-world events totaling 50ms affecting the latency for all the active threads at that very moment. But if you were trying to optimize for throughput, you would have been misguided – listing just the stop-the-world initial mark and final remark phases, the jstat output completely hides the concurrent work being done. 449 | 450 | 451 | 如果只关心延迟, 通过后面 `jstat` 显示的数据, 也能得出正确的结果。它正确地列出了两次 STW 事件,总计耗时 50 ms。这段时间影响了所有应用线程的延迟。如果想要优化吞吐量, 这个结果就会有误导性 —— jstat 只列出了 stop-the-world 的初始标记阶段和最终标记阶段, jstat 的输出完全隐藏了并发执行的GC阶段。 452 | 453 | 454 | 原文链接: [Garbage Collection in Java](https://plumbr.eu/handbook/garbage-collection-in-java) 455 | 456 | 457 | 458 |
459 | 460 | 461 | -------------------------------------------------------------------------------- /02_Garbage_Collection_in_Java_CN.md: -------------------------------------------------------------------------------- 1 | # 2. Java中的垃圾收集 2 | 3 | 4 | **标记-清除**(Mark and Sweep)是最经典的垃圾收集算法。将理论用于生产实践时, 会有很多需要优化调整的地方, 以适应具体环境。下面通过一个简单的例子, 让我们一步步记录下来, 看看如何才能保证JVM能安全持续地分配对象。 5 | 6 | 7 | ## 碎片整理(Fragmenting and Compacting) 8 | 9 | 10 | 每次执行清除(sweeping), JVM 都必须保证不可达对象占用的内存能被回收重用。但这(最终)有可能会产生内存碎片(类似于磁盘碎片), 进而引发两个问题: 11 | 12 | - 写入操作越来越耗时, 因为寻找一块足够大的空闲内存会变得非常麻烦。 13 | 14 | - 在创建新对象时, JVM在连续的块中分配内存。如果碎片问题很严重, 直至没有空闲片段能存放下新创建的对象,就会发生内存分配错误(allocation error)。 15 | 16 | 17 | 要避免这类问题,JVM 必须确保碎片问题不失控。因此在垃圾收集过程中, 不仅仅是标记和清除, 还需要执行 “内存碎片整理” 过程。这个过程让所有可达对象(reachable objects)依次排列, 以消除(或减少)碎片。示意图如下所示: 18 | 19 | 20 | ![](02_01_fragmented-vs-compacted-heap.png) 21 | 22 | 23 | > **说明**: 24 | > 25 | > JVM中的引用是一个抽象的概念,如果GC移动某个对象, 就会修改(栈和堆中)所有指向该对象的引用。 26 | > 27 | > 移动/拷贝/提升/压缩 是一个 STW 的过程,所以修改对象引用是一个安全的行为。但要更新所有的引用,对某些程序可能性能低下。 28 | 29 | 30 | ## 分代假设(Generational Hypothesis) 31 | 32 | 33 | 我们前面提到过,执行垃圾收集需要停止整个应用。很明显,对象越多则收集所有垃圾消耗的时间就越长。但可不可以只处理一个较小的内存区域呢? 为了探究这种可能性,研究人员发现,程序中的大多数可回收的内存可归为两类: 34 | 35 | - 大部分对象很快就不再使用 36 | 37 | - 还有一部分不会立即无用,但也不会持续(太)长时间 38 | 39 | 40 | 这些观测形成了 **弱代假设**(Weak Generational Hypothesis)。基于这一假设, VM中的内存被分为**年轻代**(Young Generation)和**老年代**(Old Generation)。老年代有时候也称为 **年老区**(Tenured)。 41 | 42 | ![](02_02_object-age-based-on-GC-gen-hypothesis.png) 43 | 44 | 45 | 拆分为这样两个可清理的单独区域，允许采用不同的算法来大幅提高GC的性能。 46 | 47 | 这种方法也不是没有问题。例如，在不同分代中的对象可能会互相引用, 在收集某一个分代时就会成为 "事实上的" GC root。 48 | 49 | 当然,要着重强调的是,分代假设并不适用于所有程序。因为GC算法专门针对“要么死得快”，“否则活得长” 这类特征的对象来进行优化, JVM对收集那种存活时间半长不长的对象就显得非常尴尬了。 50 | 51 | 52 | ## 内存池(Memory Pools) 53 | 54 | 堆内存中的内存池划分也是类似的。不太容易理解的地方在于各个内存池中的垃圾收集是如何运行的。请注意,不同的GC算法在实现细节上可能会有所不同,但和本章所介绍的相关概念都是一致的。 55 | 56 | 57 | ![](02_03_java-heap-eden-survivor-old.png) 58 | 59 | 60 | ### 新生代(Eden,伊甸园) 61 | 62 | 63 | Eden 是内存中的一个区域, 用来分配新创建的对象。通常会有多个线程同时创建多个对象, 所以 Eden 区被划分为多个 **线程本地分配缓冲区**(Thread Local Allocation Buffer, 简称TLAB)。通过这种缓冲区划分,大部分对象直接由JVM 在对应线程的TLAB中分配, 避免与其他线程的同步操作。 64 | 65 | 如果 TLAB 中没有足够的内存空间, 就会在共享Eden区(shared Eden space)之中分配。如果共享Eden区也没有足够的空间, 就会触发一次 年轻代GC 来释放内存空间。如果GC之后 Eden 区依然没有足够的空闲内存区域, 则对象就会被分配到老年代空间(Old Generation)。 66 | 67 | 当 Eden 区进行垃圾收集时, GC将所有从 root 可达的对象过一遍, 并标记为存活对象。 68 | 69 | 70 | 我们曾指出,对象间可能会有跨代的引用, 所以需要一种方法来标记从其他分代中指向Eden的所有引用。这样做又会遭遇各个分代之间一遍又一遍的引用。JVM在实现时采用了一些绝招: 卡片标记(card-marking)。从本质上讲,JVM只需要记住Eden区中 “脏”对象的粗略位置, 可能有老年代的对象引用指向这部分区间。更多细节请参考: [Nitsan 的博客](http://psy-lob-saw.blogspot.com/2014/10/the-jvm-write-barrier-card-marking.html) 。 71 | 72 | 73 | ![](02_04_TLAB-in-Eden-memory.png) 74 | 75 | 76 | 标记阶段完成后, Eden中所有存活的对象都会被复制到存活区(Survivor spaces)里面。整个Eden区就可以被认为是空的, 然后就能用来分配新对象。这种方法称为 “**标记-复制**”(Mark and Copy): 存活的对象被标记, 然后复制到一个存活区(注意,是复制,而不是移动)。 77 | 78 | ### 存活区(Survivor Spaces) 79 | 80 | Eden 区的旁边是两个**存活区**, 称为 `from 空间`和 `to 空间`。需要着重强调的的是, 任意时刻总有一个存活区是空的(empty)。 81 | 82 | 83 | 空的那个存活区用于在下一次年轻代GC时存放收集的对象。年轻代中所有的存活对象(包括Edenq区和非空的那个 "from" 存活区)都会被复制到 ”to“ 存活区。GC过程完成后, ”to“ 区有对象,而 'from' 区里没有对象。两者的角色进行正好切换 。 84 | 85 | 86 | ![](02_05_how-java-gc-works.png) 87 | 88 | 89 | 存活的对象会在两个存活区之间复制多次, 直到某些对象的存活 时间达到一定的阀值。分代理论假设, 存活超过一定时间的对象很可能会继续存活更长时间。 90 | 91 | 这类“ 年老” 的对象因此被**提升**(promoted )到老年代。提升的时候， 存活区的对象不再是复制到另一个存活区,而是迁移到老年代, 并在老年代一直驻留, 直到变为不可达对象。 92 | 93 | 94 | 为了确定一个对象是否“足够老”, 可以被提升(Promotion)到老年代，GC模块跟踪记录每个存活区对象存活的次数。每次分代GC完成后,存活对象的年龄就会增长。当年龄超过**提升阈值**(tenuring threshold), 就会被提升到老年代区域。 95 | 96 | 97 | 具体的提升阈值由JVM动态调整,但也可以用参数 `-XX:+MaxTenuringThreshold` 来指定上限。如果设置 `-XX:+MaxTenuringThreshold=0` , 则GC时存活对象不在存活区之间复制，直接提升到老年代。现代 JVM 中这个阈值默认设置为**15**个 GC周期。这也是HotSpot中的最大值。 98 | 99 | 100 | 如果存活区空间不够存放年轻代中的存活对象，提升(Promotion)也可能更早地进行。 101 | 102 | ### 老年代(Old Generation) 103 | 104 | 105 | 老年代的GC实现要复杂得多。老年代内存空间通常会更大，里面的对象是垃圾的概率也更小。 106 | 107 | 108 | 老年代GC发生的频率比年轻代小很多。同时, 因为预期老年代中的对象大部分是存活的, 所以不再使用标记和复制(Mark and Copy)算法。而是采用移动对象的方式来实现最小化内存碎片。老年代空间的清理算法通常是建立在不同的基础上的。原则上,会执行以下这些步骤: 109 | 110 | 111 | - 通过标志位(marked bit),标记所有通过 GC roots 可达的对象. 112 | 113 | - 删除所有不可达对象 114 | 115 | - 整理老年代空间中的内容，方法是将所有的存活对象复制,从老年代空间开始的地方,依次存放。 116 | 117 | 118 | 通过上面的描述可知, 老年代GC必须明确地进行整理,以避免内存碎片过多。 119 | 120 | ### 永久代(PermGen) 121 | 122 | 123 | 124 | 在Java 8 之前有一个特殊的空间,称为“永久代”(Permanent Generation)。这是存储元数据(metadata)的地方,比如 class 信息等。此外,这个区域中也保存有其他的数据和信息, 包括 内部化的字符串(internalized strings)等等。实际上这给Java开发者造成了很多麻烦,因为很难去计算这块区域到底需要占用多少内存空间。预测失败导致的结果就是产生 [`java.lang.OutOfMemoryError: Permgen space`](https://plumbr.eu/outofmemoryerror/permgen-space) 这种形式的错误。除非 ·OutOfMemoryError· 确实是内存泄漏导致的,否则就只能增加 permgen 的大小，例如下面的示例，就是设置 permgen 最大空间为 256 MB: 125 | 126 | 127 | java -XX:MaxPermSize=256m com.mycompany.MyApplication 128 | 129 | ### 元数据区(Metaspace) 130 | 131 | 132 | 既然估算元数据所需空间那么复杂, Java 8直接删除了永久代(Permanent Generation)，改用 Metaspace。从此以后, Java 中很多杂七杂八的东西都放置到普通的堆内存里。 133 | 134 | 135 | 当然，像类定义(class definitions)之类的信息会被加载到 Metaspace 中。元数据区位于本地内存(native memory),不再影响到普通的Java对象。默认情况下, Metaspace的大小只受限于 Java进程可用的本地内存。这样程序就不再因为多加载了几个类/JAR包就导致 [`java.lang.OutOfMemoryError: Permgen space. `](https://plumbr.eu/outofmemoryerror/permgen-space) 。注意, 这种不受限制的空间也不是没有代价的 —— 如果 Metaspace 失控, 则可能会导致很严重的内存交换(swapping), 或者导致本地内存分配失败。 136 | 137 | 138 | 如果需要避免这种最坏情况，那么可以通过下面这样的方式来限制 Metaspace 的大小, 如 256 MB: 139 | 140 | 141 | java -XX:MaxMetaspaceSize=256m com.mycompany.MyApplication 142 | 143 | 144 | ## Minor GC vs Major GC vs Full GC 145 | 146 | 147 | 垃圾收集事件(Garbage Collection events)通常分为: 小型GC(Minor GC) - 大型GC(Major GC) - 和完全GC(Full GC) 。本节介绍这些事件及其区别。然后你会发现这些区别也不是特别清晰。 148 | 149 | 150 | 最重要的是,应用程序是否满足 服务级别协议(Service Level Agreement, SLA), 并通过监控程序查看响应延迟和吞吐量。也只有那时候才能看到GC事件相关的结果。重要的是这些事件是否停止整个程序,以及持续多长时间。 151 | 152 | 虽然 Minor, Major 和 Full GC 这些术语被广泛应用, 但并没有标准的定义, 我们还是来深入了解一下具体的细节吧。 153 | 154 | ### 小型GC(Minor GC) 155 | 156 | 年轻代内存的垃圾收集事件称为**小型GC**。这个定义既清晰又得到广泛共识。对于小型GC事件,有一些有趣的事情你应该了解一下: 157 | 158 | 1. 当JVM无法为新对象分配内存空间时总会触发 Minor GC,比如 Eden 区占满时。所以(新对象)分配频率越高, Minor GC 的频率就越高。 159 | 2. Minor GC 事件实际上忽略了老年代。从老年代指向年轻代的引用都被认为是GC Root。而从年轻代指向老年代的引用在标记阶段全部被忽略。 160 | 3. 与一般的认识相反, Minor GC 每次都会引起全线停顿(stop-the-world ), 暂停所有的应用线程。对大多数程序而言,暂停时长基本上是可以忽略不计的, 因为 Eden 区的对象基本上都是垃圾, 也不怎么复制到存活区/老年代。如果情况不是这样, 大部分新创建的对象不能被垃圾回收清理掉, 则 Minor GC的停顿就会持续更长的时间。 161 | 162 | 163 | 所以 Minor GC 的定义很简单 —— **Minor GC 清理的就是年轻代**。 164 | 165 | 166 | ### Major GC vs Full GC 167 | 168 | 169 | 值得一提的是, 这些术语并没有正式的定义 —— 无论是在JVM规范还是在GC相关论文中。 170 | 171 | 我们知道, Minor GC 清理的是年轻代空间(Young space)，相应的,其他定义也很简单: 172 | 173 | - **Major GC**(大型GC) 清理的是老年代空间(Old space)。 174 | - **Full GC**(完全GC)清理的是整个堆, 包括年轻代和老年代空间。 175 | 176 | 177 | 杯具的是更复杂的情况出现了。很多 Major GC 是由 Minor GC 触发的, 所以很多情况下这两者是不可分离的。另一方面, 像G1这样的垃圾收集算法执行的是部分区域垃圾回收, 所以，额，使用术语“cleaning”并不是非常准确。 178 | 179 | 这也让我们认识到,**不应该去操心是叫 Major GC 呢还是叫 Full GC, 我们应该关注的是: 某次GC事件 是否停止所有线程,或者是与其他线程并发执行**。 180 | 181 | 182 | 这些混淆甚至根植于标准的JVM工具中。我的意思可以通过实例来说明。让我们来对比同一JVM中两款工具的GC信息输出吧。这个JVM使用的是 **并发标记和清除收集器**（Concurrent Mark and Sweep collector，`-XX:+UseConcMarkSweepGC`). 183 | 184 | 185 | 首先我们来看 [`jstat`](http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html) 的输出: 186 | 187 | 188 | > `jstat -gc -t 4235 1s` 189 | 190 | 191 | 192 | Time S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 193 | 5.7 34048.0 34048.0 0.0 34048.0 272640.0 194699.7 1756416.0 181419.9 18304.0 17865.1 2688.0 2497.6 3 0.275 0 0.000 0.275 194 | 6.7 34048.0 34048.0 34048.0 0.0 272640.0 247555.4 1756416.0 263447.9 18816.0 18123.3 2688.0 2523.1 4 0.359 0 0.000 0.359 195 | 7.7 34048.0 34048.0 0.0 34048.0 272640.0 257729.3 1756416.0 345109.8 19072.0 18396.6 2688.0 2550.3 5 0.451 0 0.000 0.451 196 | 8.7 34048.0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0 444982.5 19456.0 18681.3 2816.0 2575.8 7 0.550 0 0.000 0.550 197 | 9.7 34048.0 34048.0 34046.7 0.0 272640.0 16777.0 1756416.0 587906.3 20096.0 19235.1 2944.0 2631.8 8 0.720 0 0.000 0.720 198 | 10.7 34048.0 34048.0 0.0 34046.2 272640.0 80171.6 1756416.0 664913.4 20352.0 19495.9 2944.0 2657.4 9 0.810 0 0.000 0.810 199 | 11.7 34048.0 34048.0 34048.0 0.0 272640.0 129480.8 1756416.0 745100.2 20608.0 19704.5 2944.0 2678.4 10 0.896 0 0.000 0.896 200 | 12.7 34048.0 34048.0 0.0 34046.6 272640.0 164070.7 1756416.0 822073.7 20992.0 19937.1 3072.0 2702.8 11 0.978 0 0.000 0.978 201 | 13.7 34048.0 34048.0 34048.0 0.0 272640.0 211949.9 1756416.0 897364.4 21248.0 20179.6 3072.0 2728.1 12 1.087 1 0.004 1.091 202 | 14.7 34048.0 34048.0 0.0 34047.1 272640.0 245801.5 1756416.0 597362.6 21504.0 20390.6 3072.0 2750.3 13 1.183 2 0.050 1.233 203 | 15.7 34048.0 34048.0 0.0 34048.0 272640.0 21474.1 1756416.0 757347.0 22012.0 20792.0 3200.0 2791.0 15 1.336 2 0.050 1.386 204 | 16.7 34048.0 34048.0 34047.0 0.0 272640.0 48378.0 1756416.0 838594.4 22268.0 21003.5 3200.0 2813.2 16 1.433 2 0.050 1.484 205 | 206 | 207 | 此片段截取自JVM启动后的前17秒。根据这些信息可以得知: 有2次Full GC在12次Minor GC(YGC)之后触发执行, 总计耗时 **50ms**。当然,也可以通过具备图形界面的工具得出同样的信息, 比如 [jconsole](http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html) 或者 [jvisualvm](http://download.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html) (或者最新的 jmc)。 208 | 209 | 210 | 在下结论之前, 让我们看看此JVM进程的GC日志。显然需要配置 `-XX:+PrintGCDetails` 参数,GC日志的内容更详细,结果也有一些不同: 211 | 212 | 213 | > `java -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer` 214 | 215 | 3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K->34048K(306688K), 0.0844702 secs] 272640K->69574K(2063104K), 0.0845560 secs] [Times: user=0.23 sys=0.03, real=0.09 secs] 216 | 4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K->34048K(306688K), 0.1013723 secs] 342214K->136584K(2063104K), 0.1014307 secs] [Times: user=0.25 sys=0.05, real=0.10 secs] 217 | ... cut for brevity ... 218 | 219 | 11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K->34048K(306688K), 0.0857219 secs] 971599K->779148K(2063104K), 0.0857875 secs] [Times: user=0.26 sys=0.04, real=0.09 secs] 220 | 12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K->34046K(306688K), 0.0821774 secs] 1051788K->856120K(2063104K), 0.0822400 secs] [Times: user=0.25 sys=0.03, real=0.08 secs] 221 | 12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K->34048K(306688K), 0.1086667 secs] 1128760K->931412K(2063104K), 0.1087416 secs] [Times: user=0.24 sys=0.04, real=0.11 secs] 222 | 13.098: [GC (CMS Initial Mark) [1 CMS-initial-mark: 897364K(1756416K)] 936667K(2063104K), 0.0041705 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 223 | 13.102: [CMS-concurrent-mark-start] 224 | 13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01, real=0.24 secs] 225 | 13.341: [CMS-concurrent-preclean-start] 226 | 13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 227 | 13.350: [CMS-concurrent-abortable-preclean-start] 228 | 13.878: [GC (Allocation Failure) 13.878: [ParNew: 306688K->34047K(306688K), 0.0960456 secs] 1204052K->1010638K(2063104K), 0.0961542 secs] [Times: user=0.29 sys=0.04, real=0.09 secs] 229 | 14.366: [CMS-concurrent-abortable-preclean: 0.917/1.016 secs] [Times: user=2.22 sys=0.07, real=1.01 secs] 230 | 14.366: [GC (CMS Final Remark) [YG occupancy: 182593 K (306688 K)]14.366: [Rescan (parallel) , 0.0291598 secs]14.395: [weak refs processing, 0.0000232 secs]14.395: [class unloading, 0.0117661 secs]14.407: [scrub symbol table, 0.0015323 secs]14.409: [scrub string table, 0.0003221 secs][1 CMS-remark: 976591K(1756416K)] 1159184K(2063104K), 0.0462010 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 231 | 14.412: [CMS-concurrent-sweep-start] 232 | 14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00, real=0.22 secs] 233 | 14.633: [CMS-concurrent-reset-start] 234 | 14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 235 | 236 | 237 | 通过GC日志可以看到, 在12 次 Minor GC之后发生了一些 "不同的事情"。并不是两个 Full GC, 而是在老年代执行了一次 GC, 分为多个阶段执行: 238 | 239 | 240 | - 初始标记阶段(Initial Mark phase),耗时 0.0041705秒(约4ms)。此阶段是全线停顿(STW)事件,暂停所有应用线程,以便执行初始标记。 241 | - 标记和预清理阶段(Markup and Preclean phase)。和应用线程并发执行。 242 | - 最终标记阶段(Final Remark phase), 耗时 0.0462010秒(约46ms)。此阶段也是全线停顿(STW)事件。 243 | - 清除操作(Sweep)是并发执行的, 不需要暂停应用线程。 244 | 245 | 246 | 所以从实际的GC日志可以看到, 并不是执行了两次 Full GC操作, 而是只执行了一次清理老年代空间的 Major GC 。 247 | 248 | 如果只关心延迟, 通过后面 `jstat` 显示的数据, 也能得出正确的结果。它正确地列出了两次 STW 事件,总计耗时 50 ms。这段时间影响了所有应用线程的延迟。如果想要优化吞吐量, 这个结果就会有误导性 —— jstat 只列出了 stop-the-world 的初始标记阶段和最终标记阶段, jstat 的输出完全隐藏了并发执行的GC阶段。 249 | 250 | 251 | 原文链接: [Garbage Collection in Java](https://plumbr.eu/handbook/garbage-collection-in-java) 252 | 253 | -------------------------------------------------------------------------------- /03_01_Java-GC-mark-and-sweep.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/03_01_Java-GC-mark-and-sweep.png -------------------------------------------------------------------------------- /03_02_GC-sweep.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/03_02_GC-sweep.png -------------------------------------------------------------------------------- /03_03_GC-mark-sweep-compact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/03_03_GC-mark-sweep-compact.png -------------------------------------------------------------------------------- /03_04_GC-mark-and-copy-in-Java.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/03_04_GC-mark-and-copy-in-Java.png -------------------------------------------------------------------------------- /03_GC_Algorithms_Basics.md: -------------------------------------------------------------------------------- 1 | # 3. GC 算法(基础篇) 2 | 3 | > **相关术语翻译说明**: 4 | > 5 | > Mark,标记; 6 | > 7 | > Sweep,清除; 8 | > 9 | > Compact,整理; 也有人翻译为压缩,译者认为GC时不存在压缩这回事。 10 | > 11 | > Copy,复制; copy 用作名词时一般翻译为拷贝/副本,用作动词时翻译为复制。 12 | > 13 | > 注: 《[垃圾回收算法手册](https://book.douban.com/subject/26740958/)》将 Mark and Sweep 翻译为: **标记-清扫**算法; 译者认为 **标记-清除** 更容易理解。 14 | 15 | 16 | Before diving into the practical implementation details of Garbage Collection algorithms it will be beneficial to define the required terminology and to understand the basic principles supporting the implementations. Specific details vary from collector to collector but in general all collectors focus in two areas 17 | 18 | 本章简要介绍GC的基本原理和相关技术, [下一章节](04_GC_Algorithms_Implementations.md)再详细讲解GC算法的具体实现。各种垃圾收集器的实现细节虽然并不相同,但总体而言,垃圾收集器都专注于两件事情: 19 | 20 | 21 | - find out all objects that are still alive 22 | - get rid of everything else – the supposedly dead and unused objects. 23 | 24 | - 查找所有存活对象 25 | - 抛弃其他的部分,即死对象,不再使用的对象。 26 | 27 | 28 | 29 | 30 | First part, the census on live objects, is implemented in all collectors with the help of a process called **Marking**. 31 | 32 | 第一步, 记录(census)所有的存活对象, 在垃圾收集中有一个叫做 **标记(Marking)** 的过程专门干这件事。 33 | 34 | 35 | 36 | ## 标记可达对象(Marking Reachable Objects) 37 | 38 | 39 | 40 | Every modern GC algorithm used in JVM starts its job with finding out all objects that are still alive. This concept is best explained using the following picture representing your JVM’s memory layout: 41 | 42 | 现代JVM中所有的GC算法,第一步都是找出所有存活的对象。下面的示意图对此做了最好的诠释: 43 | 44 | 45 | ![](03_01_Java-GC-mark-and-sweep.png) 46 | 47 | 48 | 49 | 50 | First, GC defines some specific objects as **Garbage Collection Roots**. Examples of such GC roots are: 51 | 52 | 首先,有一些特定的对象被指定为 **Garbage Collection Roots**(GC根元素)。包括: 53 | 54 | 55 | - Local variable and input parameters of the currently executing methods 56 | - Active threads 57 | - Static field of the loaded classes 58 | - JNI references 59 | 60 | - 当前正在执行的方法里的局部变量和输入参数 61 | - 活动线程(Active threads) 62 | - 内存中所有类的静态字段(static field) 63 | - JNI引用 64 | 65 | 66 | Next, GC traverses the whole object graph in your memory, starting from those Garbage Collection Roots and following references from the roots to other objects, e.g. instance fields. Every object the GC visits is **marked** as alive. 67 | 68 | 69 | 其次, GC遍历(traverses)内存中整体的对象关系图(object graph),从GC根元素开始扫描, 到直接引用，以及其他对象(通过对象的属性域)。所有GC访问到的对象都被**标记(marked)**为存活对象。 70 | 71 | 72 | 73 | Live objects are represented as blue on the picture above. When the marking phase finishes, every live object is marked. All other objects (grey data structures on the picture above) are thus unreachable from the GC roots, implying that your application cannot use the unreachable objects anymore. Such objects are considered garbage and GC should get rid of them in the following phases. 74 | 75 | 76 | 存活对象在上图中用蓝色表示。标记阶段完成后, 所有存活对象都被标记了。而其他对象(上图中灰色的数据结构)就是从GC根元素不可达的, 也就是说程序不能再使用这些不可达的对象(unreachable object)。这样的对象被认为是垃圾, GC会在接下来的阶段中清除他们。 77 | 78 | 79 | 80 | 81 | There are important aspects to note about the marking phase: 82 | 83 | 在标记阶段有几个需要注意的点: 84 | 85 | 86 | 87 | The application threads need to be stopped for the marking to happen as you cannot really traverse the graph if it keeps changing under your feet all the time. Such a situation when the application threads are temporarily stopped so that the JVM can indulge in housekeeping activities is called a **safe point** resulting in a **Stop The World pause**. Safe points can be triggered for different reasons but garbage collection is by far the most common reason for a safe point to be introduced. 88 | 89 | 90 | 在标记阶段,需要暂停所有应用线程, 以遍历所有对象的引用关系。因为不暂停就没法跟踪一直在变化的引用关系图。这种情景叫做 **Stop The World pause** (**全线停顿**),而可以安全地暂停线程的点叫做安全点(safe point), 然后, JVM就可以专心执行清理工作。安全点可能有多种因素触发, 当前, GC是触发安全点最常见的原因。 91 | 92 | 93 | 94 | The duration of this pause depends neither on the total number of objects in heap nor on the size of the heap but on the number of **alive objects**. So increasing the size of the heap does not directly affect the duration of the marking phase. 95 | 96 | 97 | 此阶段暂停的时间, 与堆内存大小,对象的总数没有直接关系, 而是由**存活对象**(alive objects)的数量来决定。所以增加堆内存的大小并不会直接影响标记阶段占用的时间。 98 | 99 | 100 | 101 | When the **mark** phase is completed, the GC can proceed to the next step and start removing the unreachable objects. 102 | 103 | 104 | **标记** 阶段完成后, GC进行下一步操作, 删除不可达对象。 105 | 106 | 107 | 108 | ## 删除不可达对象(Removing Unused Objects) 109 | 110 | 111 | Removal of unused objects is somewhat different for different GC algorithms but all such GC algorithms can be divided into three groups: sweeping, compacting and copying. Next sections will discuss each of such algorithms in more detail. 112 | 113 | 114 | 各种GC算法在删除不可达对象时略有不同, 但总体可分为三类: 清除(sweeping)、整理(compacting)和复制(copying)。[下一章节](04_GC_Algorithms_Implementations.md)将详细讲解这些算法。 115 | 116 | 117 | 118 | ### Sweep 119 | 120 | ### Sweep(清除) 121 | 122 | 123 | **Mark and Sweep** algorithms use conceptually the simplest approach to garbage by just ignoring such objects. What this means is that after the marking phase has completed all space occupied by unvisited objects is considered free and can thus be reused to allocate new objects. 124 | 125 | 126 | 127 | 128 | **Mark and Sweep(标记-清除)** 算法的概念非常简单: 直接忽略所有的垃圾。也就是说在标记阶段完成后, 所有不可达对象占用的内存空间, 都被认为是空闲的, 因此可以用来分配新对象。 129 | 130 | 131 | 132 | 133 | The approach requires using the so called **free-list** recording of every free region and its size. The management of the free-lists adds overhead to object allocation. Built into this approach is another weakness – there may exist plenty of free regions but if no single region is large enough to accommodate the allocation, the allocation is still going to fail (with an [OutOfMemoryError](http://plumbr.eu/outofmemoryerror) in Java). 134 | 135 | 136 | 这种算法需要使用 **空闲表(free-list)**,来记录所有的空闲区域, 以及每个区域的大小。维护空闲表增加了对象分配时的开销。此外还存在另一个弱点 —— 明明还有很多空闲内存, 却可能没有一个区域的大小能够存放需要分配的对象, 从而导致分配失败(在Java 中就是 [OutOfMemoryError](http://plumbr.eu/outofmemoryerror))。 137 | 138 | 139 | 140 | ![](03_02_GC-sweep.png) 141 | 142 | 143 | 144 | ### Compact(整理) 145 | 146 | 147 | **Mark-Sweep-Compact** algorithms solve the shortcomings of Mark and Sweep by moving all marked – and thus alive – objects to the beginning of the memory region. The downside of this approach is an increased GC pause duration as we need to copy all objects to a new place and to update all references to such objects. The benefits to Mark and Sweep are also visible – after such a compacting operation new object allocation is again extremely cheap via pointer bumping. Using such approach the location of the free space is always known and no fragmentation issues are triggered either. 148 | 149 | 150 | **标记-清除-整理算法(Mark-Sweep-Compact)**, 将所有被标记的对象(存活对象), 迁移到内存空间的起始处, 消除了标记-清除算法的缺点。 相应的缺点就是GC暂停时间会增加, 因为需要将所有对象复制到另一个地方, 然后修改指向这些对象的引用。此算法的优势也很明显, 碎片整理之后, 分配新对象就很简单, 只需要通过指针碰撞(pointer bumping)即可。使用这种算法, 内存空间剩余的容量一直是清楚的, 不会再导致内存碎片问题。 151 | 152 | 153 | 154 | ![](03_03_GC-mark-sweep-compact.png) 155 | 156 | 157 | 158 | 159 | 160 | ### Copy 161 | 162 | ### Copy(复制) 163 | 164 | 165 | **Mark and Copy** algorithms are very similar to the Mark and Compact as they too relocate all live objects. The important difference is that the target of relocation is a different memory region as a new home for survivors. Mark and Copy approach has some advantages as copying can occur simultaneously with marking during the same phase. The disadvantage is the need for one more memory region, which should be large enough to accommodate survived objects. 166 | 167 | 168 | **标记-复制算法(Mark and Copy)** 和 标记-整理算法(Mark and Compact) 十分相似: 两者都会移动所有存活的对象。区别在于, 标记-复制算法是将内存移动到另外一个空间: 存活区。标记-复制方法的优点在于: 标记和复制可以同时进行。缺点则是需要一个额外的内存区间, 来存放所有的存活对象。 169 | 170 | 171 | 172 | ![](03_04_GC-mark-and-copy-in-Java.png) 173 | 174 | 175 | 176 | 177 | 178 | 原文链接: [GC Algorithms: Basics](https://plumbr.eu/handbook/garbage-collection-algorithms) 179 | 180 | 181 | 182 | 183 | 184 |
185 | 186 | 187 | -------------------------------------------------------------------------------- /03_GC_Algorithms_Basics_CN.md: -------------------------------------------------------------------------------- 1 | # 3. GC 算法(基础篇) 2 | 3 | > **相关术语翻译说明**: 4 | > 5 | > Mark,标记; 6 | > 7 | > Sweep,清除; 8 | > 9 | > Compact,整理; 也有人翻译为压缩,译者认为GC时不存在压缩这回事。 10 | > 11 | > Copy,复制; copy 用作名词时一般翻译为拷贝/副本,用作动词时翻译为复制。 12 | > 13 | > 注: 《[垃圾回收算法手册](https://book.douban.com/subject/26740958/)》将 Mark and Sweep 翻译为: **标记-清扫**算法; 译者认为 **标记-清除** 更容易理解。 14 | 15 | 16 | 本章简要介绍GC的基本原理和相关技术, [下一章节](04_GC_Algorithms_Implementations.md)再详细讲解GC算法的具体实现。各种垃圾收集器的实现细节虽然并不相同,但总体而言,垃圾收集器都专注于两件事情: 17 | 18 | - 查找所有存活对象 19 | - 抛弃其他的部分,即死对象,不再使用的对象。 20 | 21 | 22 | 第一步, 记录(census)所有的存活对象, 在垃圾收集中有一个叫做 **标记(Marking)** 的过程专门干这件事。 23 | 24 | 25 | ## 标记可达对象(Marking Reachable Objects) 26 | 27 | 28 | 现代JVM中所有的GC算法,第一步都是找出所有存活的对象。下面的示意图对此做了最好的诠释: 29 | 30 | 31 | ![](03_01_Java-GC-mark-and-sweep.png) 32 | 33 | 34 | 首先,有一些特定的对象被指定为 **Garbage Collection Roots**(GC根元素)。包括: 35 | 36 | 37 | - 当前正在执行的方法里的局部变量和输入参数 38 | - 活动线程(Active threads) 39 | - 内存中所有类的静态字段(static field) 40 | - JNI引用 41 | 42 | 43 | 其次, GC遍历(traverses)内存中整体的对象关系图(object graph),从GC根元素开始扫描, 到直接引用，以及其他对象(通过对象的属性域)。所有GC访问到的对象都被**标记(marked)**为存活对象。 44 | 45 | 46 | 存活对象在上图中用蓝色表示。标记阶段完成后, 所有存活对象都被标记了。而其他对象(上图中灰色的数据结构)就是从GC根元素不可达的, 也就是说程序不能再使用这些不可达的对象(unreachable object)。这样的对象被认为是垃圾, GC会在接下来的阶段中清除他们。 47 | 48 | 49 | 在标记阶段有几个需要注意的点: 50 | 51 | 52 | 在标记阶段,需要暂停所有应用线程, 以遍历所有对象的引用关系。因为不暂停就没法跟踪一直在变化的引用关系图。这种情景叫做 **Stop The World pause** (**全线停顿**),而可以安全地暂停线程的点叫做安全点(safe point), 然后, JVM就可以专心执行清理工作。安全点可能有多种因素触发, 当前, GC是触发安全点最常见的原因。 53 | 54 | 55 | 此阶段暂停的时间, 与堆内存大小,对象的总数没有直接关系, 而是由**存活对象**(alive objects)的数量来决定。所以增加堆内存的大小并不会直接影响标记阶段占用的时间。 56 | 57 | 58 | **标记** 阶段完成后, GC进行下一步操作, 删除不可达对象。 59 | 60 | 61 | ## 删除不可达对象(Removing Unused Objects) 62 | 63 | 64 | 各种GC算法在删除不可达对象时略有不同, 但总体可分为三类: 清除(sweeping)、整理(compacting)和复制(copying)。[下一章节](04_GC_Algorithms_Implementations.md)将详细讲解这些算法。 65 | 66 | 67 | ### Sweep(清除) 68 | 69 | 70 | **Mark and Sweep(标记-清除)** 算法的概念非常简单: 直接忽略所有的垃圾。也就是说在标记阶段完成后, 所有不可达对象占用的内存空间, 都被认为是空闲的, 因此可以用来分配新对象。 71 | 72 | 73 | 这种算法需要使用 **空闲表(free-list)**,来记录所有的空闲区域, 以及每个区域的大小。维护空闲表增加了对象分配时的开销。此外还存在另一个弱点 —— 明明还有很多空闲内存, 却可能没有一个区域的大小能够存放需要分配的对象, 从而导致分配失败(在Java 中就是 [OutOfMemoryError](http://plumbr.eu/outofmemoryerror))。 74 | 75 | 76 | ![](03_02_GC-sweep.png) 77 | 78 | 79 | ### Compact(整理) 80 | 81 | 82 | **标记-清除-整理算法(Mark-Sweep-Compact)**, 将所有被标记的对象(存活对象), 迁移到内存空间的起始处, 消除了标记-清除算法的缺点。 相应的缺点就是GC暂停时间会增加, 因为需要将所有对象复制到另一个地方, 然后修改指向这些对象的引用。此算法的优势也很明显, 碎片整理之后, 分配新对象就很简单, 只需要通过指针碰撞(pointer bumping)即可。使用这种算法, 内存空间剩余的容量一直是清楚的, 不会再导致内存碎片问题。 83 | 84 | 85 | ![](03_03_GC-mark-sweep-compact.png) 86 | 87 | 88 | ### Copy(复制) 89 | 90 | 91 | **标记-复制算法(Mark and Copy)** 和 标记-整理算法(Mark and Compact) 十分相似: 两者都会移动所有存活的对象。区别在于, 标记-复制算法是将内存移动到另外一个空间: 存活区。标记-复制方法的优点在于: 标记和复制可以同时进行。缺点则是需要一个额外的内存区间, 来存放所有的存活对象。 92 | 93 | 94 | ![](03_04_GC-mark-and-copy-in-Java.png) 95 | 96 | 97 | 原文链接: [GC Algorithms: Basics](https://plumbr.eu/handbook/garbage-collection-algorithms) 98 | 99 | -------------------------------------------------------------------------------- /04_01_serial-gc-in-young-generation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_01_serial-gc-in-young-generation.png -------------------------------------------------------------------------------- /04_02_serial-gc-in-old-gen-java.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_02_serial-gc-in-old-gen-java.png -------------------------------------------------------------------------------- /04_03_ParallelGC-in-Young-Generation-Java.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_03_ParallelGC-in-Young-Generation-Java.png -------------------------------------------------------------------------------- /04_04_Java-ParallelGC-in-Old-Generation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_04_Java-ParallelGC-in-Old-Generation.png -------------------------------------------------------------------------------- /04_05_ParallelGC-in-Young-Generation-Java.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_05_ParallelGC-in-Young-Generation-Java.png -------------------------------------------------------------------------------- /04_06_g1-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_06_g1-06.png -------------------------------------------------------------------------------- /04_07_g1-07.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_07_g1-07.png -------------------------------------------------------------------------------- /04_08_g1-08.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_08_g1-08.png -------------------------------------------------------------------------------- /04_09_g1-09.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_09_g1-09.png -------------------------------------------------------------------------------- /04_10_g1-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_10_g1-10.png -------------------------------------------------------------------------------- /04_11_g1-011.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_11_g1-011.png -------------------------------------------------------------------------------- /04_12_g1-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_12_g1-02.png -------------------------------------------------------------------------------- /04_13_g1-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_13_g1-03.png -------------------------------------------------------------------------------- /04_14_g1-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_14_g1-04.png -------------------------------------------------------------------------------- /04_15_g1-05-v2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/04_15_g1-05-v2.png -------------------------------------------------------------------------------- /04_GC_Algorithms_Implementations_CN.md: -------------------------------------------------------------------------------- 1 | # 4. GC 算法(实现篇) 2 | 3 | 4 | 学习了GC算法的相关概念之后, 我们将介绍在JVM中这些算法的具体实现。首先要记住的是, 大多数JVM都需要使用两种不同的GC算法 —— 一种用来清理年轻代, 另一种用来清理老年代。 5 | 6 | 我们可以选择JVM内置的各种算法。如果不通过参数明确指定垃圾收集算法, 则会使用宿主平台的默认实现。本章会详细介绍各种算法的实现原理。 7 | 8 | 下面是关于Java 8中各种组合的垃圾收集器概要列表,对于之前的Java版本来说,可用组合会有一些不同: 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 |
YoungTenuredJVM options
Incremental(增量GC)Incremental-Xincgc
SerialSerial-XX:+UseSerialGC
Parallel ScavengeSerial-XX:+UseParallelGC -XX:-UseParallelOldGC
Parallel NewSerialN/A
SerialParallel OldN/A
Parallel ScavengeParallel Old-XX:+UseParallelGC -XX:+UseParallelOldGC
Parallel NewParallel OldN/A
SerialCMS-XX:-UseParNewGC -XX:+UseConcMarkSweepGC
Parallel ScavengeCMSN/A
Parallel NewCMS-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
G1-XX:+UseG1GC
76 | 77 | 78 | 看起来有些复杂, 不用担心。主要使用的是上表中黑体字表示的这四种组合。其余的要么是[被废弃(deprecated)](http://openjdk.java.net/jeps/173), 要么是不支持或者是不太适用于生产环境。所以,接下来我们只介绍下面这些组合及其工作原理: 79 | 80 | 81 | - 年轻代和老年代的串行GC(Serial GC) 82 | - 年轻代和老年代的并行GC(Parallel GC) 83 | - 年轻代的并行GC(Parallel New) + 老年代的CMS(Concurrent Mark and Sweep) 84 | - G1, 负责回收年轻代和老年代 85 | 86 | 87 | ## Serial GC(串行GC) 88 | 89 | 90 | Serial GC 对年轻代使用 [mark-copy(标记-复制) 算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/copy), 对老年代使用 [mark-sweep-compact(标记-清除-整理)算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/compact). 顾名思义, 两者都是单线程的垃圾收集器,不能进行并行处理。两者都会触发全线暂停(STW),停止所有的应用线程。 91 | 92 | 因此这种GC算法不能充分利用多核CPU。不管有多少CPU内核, JVM 在垃圾收集时都只能使用单个核心。 93 | 94 | 要启用此款收集器, 只需要指定一个JVM启动参数即可,同时对年轻代和老年代生效: 95 | 96 | 97 | java -XX:+UseSerialGC com.mypackages.MyExecutableClass 98 | 99 | 100 | 该选项只适合几百MB堆内存的JVM,而且是单核CPU时比较有用。 对于服务器端来说, 因为一般是多个CPU内核, 并不推荐使用, 除非确实需要限制JVM所使用的资源。大多数服务器端应用部署在多核平台上, 选择 Serial GC 就表示人为的限制系统资源的使用。 导致的就是资源闲置, 多的CPU资源也不能用来降低延迟,也不能用来增加吞吐量。 101 | 102 | 下面让我们看看Serial GC的垃圾收集日志, 并从中提取什么有用的信息。为了打开GC日志记录, 我们使用下面的JVM启动参数: 103 | 104 | 105 | -XX:+PrintGCDetails -XX:+PrintGCDateStamps 106 | -XX:+PrintGCTimeStamps 107 | 108 | 109 | 产生的GC日志输出类似这样(为了排版,已手工折行): 110 | 111 | 112 | 2015-05-26T14:45:37.987-0200: 113 | 151.126: [GC (Allocation Failure) 114 | 151.126: [DefNew: 629119K->69888K(629120K), 0.0584157 secs] 115 | 1619346K->1273247K(2027264K), 0.0585007 secs] 116 | [Times: user=0.06 sys=0.00, real=0.06 secs] 117 | 2015-05-26T14:45:59.690-0200: 118 | 172.829: [GC (Allocation Failure) 119 | 172.829: [DefNew: 629120K->629120K(629120K), 0.0000372 secs] 120 | 172.829: [Tenured: 1203359K->755802K(1398144K), 0.1855567 secs] 121 | 1832479K->755802K(2027264K), 122 | [Metaspace: 6741K->6741K(1056768K)], 0.1856954 secs] 123 | [Times: user=0.18 sys=0.00, real=0.18 secs] 124 | 125 | 126 | 127 | 此GC日志片段展示了在JVM中发生的很多事情。 实际上,在这段日志中产生了两个GC事件, 其中一次清理的是年轻代,另一次清理的是整个堆内存。让我们先来分析前一次GC,其在年轻代中产生。 128 | 129 | 130 | ### Minor GC(小型GC) 131 | 132 | 133 | 以下代码片段展示了清理年轻代内存的GC事件: 134 | 135 | 136 | > `2015-05-26T14:45:37.987-0200`1 : `151.1262`2 : [ `GC`3 (`Allocation Failure`4 151.126:
137 | > [`DefNew`5 : `629119K->69888K`6 `(629120K)`7 , 0.0584157 secs] `1619346K->1273247K`8
138 | > `(2027264K)`9, `0.0585007 secs`10] `[Times: user=0.06 sys=0.00, real=0.06 secs]`11 139 | 140 |
141 | 142 | > 1. `2015-05-26T14:45:37.987-0200` – GC事件开始的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 143 | > 144 | > 2. `151.126` – GC事件开始时,相对于JVM启动时的间隔时间,单位是秒。 145 | > 146 | > 3. `GC` – 用来区分 Minor GC 还是 Full GC 的标志。`GC`表明这是一次**小型GC**(Minor GC) 147 | > 148 | > 4. `Allocation Failure` – 触发 GC 的原因。本次GC事件, 是由于年轻代中没有空间来存放新的数据结构引起的。 149 | > 150 | > 5. `DefNew` – 垃圾收集器的名称。这个神秘的名字表示的是在年轻代中使用的: 单线程, 标记-复制(mark-copy), 全线暂停(STW) 垃圾收集器。 151 | > 152 | > 6. `629119K->69888K` – 在垃圾收集之前和之后年轻代的使用量。 153 | > 154 | > 7. `(629120K)` – 年轻代总的空间大小。 155 | > 156 | > 8. `1619346K->1273247K` – 在垃圾收集之前和之后整个堆内存的使用情况。 157 | > 158 | > 9. `(2027264K)` – 可用堆的总空间大小。 159 | > 160 | > 10. `0.0585007 secs` – GC事件持续的时间,以秒为单位。 161 | > 162 | > 11. `[Times: user=0.06 sys=0.00, real=0.06 secs]` – GC事件的持续时间, 通过三个部分来衡量: 163 | > 164 | - user – 在此次垃圾回收过程中, 所有 GC线程所消耗的CPU时间之和。 165 | 166 | > 167 | - sys – GC过程中中操作系统调用和系统等待事件所消耗的时间。 168 | > 169 | - real – 应用程序暂停的时间。因为串行垃圾收集器(Serial Garbage Collector)只使用单线程, 因此 real time 等于 user 和 system 时间的总和。 170 | 171 | 172 | 可以从上面的日志片段了解到, 在GC事件中,JVM 的内存使用情况发生了怎样的变化。此次垃圾收集之前, 堆内存总的使用量为 **1,619,346K**。其中,年轻代使用了 **629,119K**。可以算出,老年代使用量为 **990,227K**。 173 | 174 | 更重要的信息蕴含在下一批数字中, 垃圾收集之后, 年轻代的使用量减少了 **559,231K**, 但堆内存的总体使用量只下降了 **346,099K**。 从中可以算出,有 **213,132K** 的对象从年轻代提升到了老年代。 175 | 176 | 此次GC事件也可以用下面的示意图来说明, 显示的是GC开始之前, 以及刚刚结束之后, 这两个时间点内存使用情况的快照: 177 | 178 | 179 | ![](04_01_serial-gc-in-young-generation.png) 180 | 181 | 182 | ### Full GC(完全GC) 183 | 184 | 185 | 理解第一次 minor GC 事件后,让我们看看日志中的第二次GC事件: 186 | 187 | 188 | > `2015-05-26T14:45:59.690-0200`1 : `172.829`2 : [GC (Allocation Failure 172.829:
189 | > `[DefNew: 629120K->629120K(629120K), 0.0000372 secs`3] 172.829:[`Tenured`4:
190 | > `1203359K->755802K`5 `(1398144K)`6, `0.1855567 secs`7 ] `1832479K->755802K`8
191 | > `(2027264K)`9, `[Metaspace: 6741K->6741K(1056768K)]`10
192 | > `[Times: user=0.18 sys=0.00, real=0.18 secs]`11 193 | 194 | 195 |
196 | 197 | 198 | > 199 | > 1. `2015-05-26T14:45:59.690-0200` – GC事件开始的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 200 | > 2. `172.829` – GC事件开始时,相对于JVM启动时的间隔时间,单位是秒。 201 | > 3. `[DefNew: 629120K->629120K(629120K), 0.0000372 secs` – 与上面的示例类似, 因为内存分配失败,在年轻代中发生了一次 minor GC。此次GC同样使用的是 DefNew 收集器, 让年轻代的使用量从 629120K 降为 0。注意,JVM对此次GC的报告有些问题,误将年轻代认为是完全填满的。此次垃圾收集消耗了 0.0000372秒。 202 | 203 | > 1. `Tenured` – 用于清理老年代空间的垃圾收集器名称。**Tenured** 表明使用的是单线程的全线暂停垃圾收集器, 收集算法为 标记-清除-整理(mark-sweep-compact )。 204 | > 2. `1203359K->755802K` – 在垃圾收集之前和之后老年代的使用量。 205 | > 3. `(1398144K)` – 老年代的总空间大小。 206 | > 4. `0.1855567 secs` – 清理老年代所花的时间。 207 | > 5. `1832479K->755802K` – 在垃圾收集之前和之后,整个堆内存的使用情况。 208 | > 6. `(2027264K)` – 可用堆的总空间大小。 209 | > 7. `[Metaspace: 6741K->6741K(1056768K)]` – 关于 Metaspace 空间, 同样的信息。可以看出, 此次GC过程中 Metaspace 中没有收集到任何垃圾。 210 | > 8. `[Times: user=0.18 sys=0.00, real=0.18 secs]` – GC事件的持续时间, 通过三个部分来衡量: 211 | - user – 在此次垃圾回收过程中, 所有 GC线程所消耗的CPU时间之和。 212 | - sys – GC过程中中操作系统调用和系统等待事件所消耗的时间。 213 | - real – 应用程序暂停的时间。因为串行垃圾收集器(Serial Garbage Collector)只使用单线程, 因此 real time 等于 user 和 system 时间的总和。 214 | 215 | 216 | 和 Minor GC 相比,最明显的区别是 —— 在此次GC事件中, 除了年轻代, 还清理了老年代和Metaspace. 在GC事件开始之前, 以及刚刚结束之后的内存布局,可以用下面的示意图来说明: 217 | 218 | 219 | ![](04_02_serial-gc-in-old-gen-java.png) 220 | 221 | 222 | ## Parallel GC(并行GC) 223 | 224 | 225 | 并行垃圾收集器这一类组合, 在年轻代使用 [标记-复制(mark-copy)算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/copy), 在老年代使用 [标记-清除-整理(mark-sweep-compact)算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/compact)。年轻代和老年代的垃圾回收都会触发STW事件,暂停所有的应用线程来执行垃圾收集。两者在执行 标记和 复制/整理阶段时都使用多个线程, 因此得名“**(Parallel)**”。通过并行执行, 使得GC时间大幅减少。 226 | 227 | 228 | 通过命令行参数 `-XX:ParallelGCThreads=NNN` 来指定 GC 线程数。 其默认值为CPU内核数。 229 | 230 | 231 | 可以通过下面的任意一组命令行参数来指定并行GC: 232 | 233 | 234 | java -XX:+UseParallelGC com.mypackages.MyExecutableClass 235 | java -XX:+UseParallelOldGC com.mypackages.MyExecutableClass 236 | java -XX:+UseParallelGC -XX:+UseParallelOldGC com.mypackages.MyExecutableClass 237 | 238 | 239 | 并行垃圾收集器适用于多核服务器,主要目标是增加吞吐量。因为对系统资源的有效使用,能达到更高的吞吐量: 240 | 241 | 242 | - 在GC期间, 所有 CPU 内核都在并行清理垃圾, 所以暂停时间更短 243 | - 在两次GC周期的间隔期, 没有GC线程在运行,不会消耗任何系统资源 244 | 245 | 246 | 另一方面, 因为此GC的所有阶段都不能中断, 所以并行GC很容易出现长时间的卡顿. 如果延迟是系统的主要目标, 那么就应该选择其他垃圾收集器组合。 247 | 248 | > **译者注**: 长时间卡顿的意思是，此GC启动之后，属于一次性完成所有操作, 于是单次 pause 的时间会较长。 249 | 250 | 251 | 让我们看看并行垃圾收集器的GC日志长什么样, 从中我们可以得到哪些有用信息。下面的GC日志中显示了一次 minor GC 暂停 和一次 major GC 暂停: 252 | 253 | 254 | 2015-05-26T14:27:40.915-0200: 116.115: [GC (Allocation Failure) 255 | [PSYoungGen: 2694440K->1305132K(2796544K)] 256 | 9556775K->8438926K(11185152K) 257 | , 0.2406675 secs] 258 | [Times: user=1.77 sys=0.01, real=0.24 secs] 259 | 2015-05-26T14:27:41.155-0200: 116.356: [Full GC (Ergonomics) 260 | [PSYoungGen: 1305132K->0K(2796544K)] 261 | [ParOldGen: 7133794K->6597672K(8388608K)] 8438926K->6597672K(11185152K), 262 | [Metaspace: 6745K->6745K(1056768K)] 263 | , 0.9158801 secs] 264 | [Times: user=4.49 sys=0.64, real=0.92 secs] 265 | 266 | 267 | 268 | ### Minor GC(小型GC) 269 | 270 | 第一次GC事件表示发生在年轻代的垃圾收集: 271 | 272 | 273 | > `2015-05-26T14:27:40.915-0200`1: `116.115`2: `[ GC`3 (`Allocation Failure`4)
274 | > [`PSYoungGen`5: `2694440K->1305132K`6 `(2796544K)`7] `9556775K->8438926K`8
275 | > `(11185152K)`9, `0.2406675 secs`10]
276 | > `[Times: user=1.77 sys=0.01, real=0.24 secs]`11 277 | 278 | 279 |
280 | 281 | > 282 | > 1. `2015-05-26T14:27:40.915-0200` – GC事件开始的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 283 | > 2. `116.115` – GC事件开始时,相对于JVM启动时的间隔时间,单位是秒。 284 | > 3. `GC` – 用来区分 Minor GC 还是 Full GC 的标志。`GC`表明这是一次**小型GC**(Minor GC) 285 | > 4. `Allocation Failure` – 触发垃圾收集的原因。本次GC事件, 是由于年轻代中没有适当的空间存放新的数据结构引起的。 286 | > 5. `PSYoungGen` – 垃圾收集器的名称。这个名字表示的是在年轻代中使用的: 并行的 标记-复制(mark-copy), 全线暂停(STW) 垃圾收集器。 287 | > 6. `2694440K->1305132K` – 在垃圾收集之前和之后的年轻代使用量。 288 | > 7. `(2796544K)` – 年轻代的总大小。 289 | > 8. `9556775K->8438926K` – 在垃圾收集之前和之后整个堆内存的使用量。 290 | > 9. `(11185152K)` – 可用堆的总大小。 291 | > 10. `0.2406675 secs` – GC事件持续的时间,以秒为单位。 292 | > 11. `[Times: user=1.77 sys=0.01, real=0.24 secs]` – GC事件的持续时间, 通过三个部分来衡量: 293 | - user – 在此次垃圾回收过程中, 由GC线程所消耗的总的CPU时间。 294 | - sys – GC过程中中操作系统调用和系统等待事件所消耗的时间。 295 | - real – 应用程序暂停的时间。在 Parallel GC 中, 这个数字约等于: (user time + system time)/GC线程数。 这里使用了8个线程。 请注意,总有一定比例的处理过程是不能并行进行的。 296 | 297 | 298 | 299 | 所以,可以简单地算出, 在垃圾收集之前, 堆内存总使用量为 **9,556,775K**。 其中年轻代为 **2,694,440K**。同时算出老年代使用量为 **6,862,335K**. 在垃圾收集之后, 年轻代使用量减少为 **1,389,308K**, 但总的堆内存使用量只减少了 `1,117,849K`。这表示有大小为 **271,459K** 的对象从年轻代提升到老年代。 300 | 301 | 302 | ![](04_03_ParallelGC-in-Young-Generation-Java.png) 303 | 304 | 305 | ### Full GC(完全GC) 306 | 307 | 308 | 学习了并行GC如何清理年轻代之后, 下面介绍清理整个堆内存的GC日志以及如何进行分析: 309 | 310 | 311 | > `2015-05-26T14:27:41.155-0200` : `116.356` : [`Full GC` (`Ergonomics`)
312 | > `[PSYoungGen: 1305132K->0K(2796544K)]` [`ParOldGen` :`7133794K->6597672K `
313 | > `(8388608K)`] `8438926K->6597672K` `(11185152K)`,
314 | > `[Metaspace: 6745K->6745K(1056768K)] `, `0.9158801 secs`,
315 | > `[Times: user=4.49 sys=0.64, real=0.92 secs]` 316 | 317 | 318 |
319 | 320 | > 1. `2015-05-26T14:27:41.155-0200` – GC事件开始的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 321 | > 2. `116.356` – GC事件开始时,相对于JVM启动时的间隔时间,单位是秒。 我们可以看到, 此次事件在前一次 MinorGC完成之后立刻就开始了。 322 | > 3. `Full GC` – 用来表示此次是 Full GC 的标志。`Full GC`表明本次清理的是年轻代和老年代。 323 | > 4. `Ergonomics` – 触发垃圾收集的原因。`Ergonomics` 表示JVM内部环境认为此时可以进行一次垃圾收集。 324 | > 5. `[PSYoungGen: 1305132K->0K(2796544K)]` – 和上面的示例一样, 清理年轻代的垃圾收集器是名为 “PSYoungGen” 的STW收集器, 采用**标记-复制**(mark-copy)算法。 年轻代使用量从 **1305132K** 变为 `0`, 一般 Full GC 的结果都是这样。 325 | > 6. `ParOldGen` – 用于清理老年代空间的垃圾收集器类型。在这里使用的是名为 **ParOldGen** 的垃圾收集器, 这是一款并行 STW垃圾收集器, 算法为 标记-清除-整理(mark-sweep-compact)。 326 | > 7. `7133794K->6597672K ` – 在垃圾收集之前和之后老年代内存的使用情况。 327 | > 8. `(8388608K)` – 老年代的总空间大小。 328 | > 9. `8438926K->6597672K` – 在垃圾收集之前和之后堆内存的使用情况。 329 | > 10. `(11185152K)` – 可用堆内存的总容量。 330 | > 11. `[Metaspace: 6745K->6745K(1056768K)] ` – 类似的信息,关于 Metaspace 空间的。可以看出, 在GC事件中 Metaspace 里面没有回收任何对象。 331 | > 12. `0.9158801 secs` – GC事件持续的时间,以秒为单位。 332 | > 13. `[Times: user=4.49 sys=0.64, real=0.92 secs]` – GC事件的持续时间, 通过三个部分来衡量: 333 | - user – 在此次垃圾回收过程中, 由GC线程所消耗的总的CPU时间。 334 | - sys – GC过程中中操作系统调用和系统等待事件所消耗的时间。 335 | - real – 应用程序暂停的时间。在 Parallel GC 中, 这个数字约等于: (user time + system time)/GC线程数。 这里使用了8个线程。 请注意,总有一定比例的处理过程是不能并行进行的。 336 | 337 | 338 | 同样,和 Minor GC 的区别是很明显的 —— 在此次GC事件中, 除了年轻代, 还清理了老年代和 Metaspace. 在GC事件前后的内存布局如下图所示: 339 | 340 | 341 | ![](04_04_Java-ParallelGC-in-Old-Generation.png) 342 | 343 | 344 | ## Concurrent Mark and Sweep(并发标记-清除) 345 | 346 | 347 | CMS的官方名称为 “**Mostly Concurrent Mark and Sweep Garbage Collector**”(主要并发-标记-清除-垃圾收集器). 其对年轻代采用并行 STW方式的 [mark-copy (标记-复制)算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/copy), 对老年代主要使用并发 [mark-sweep (标记-清除)算法](https://plumbr.eu/handbook/garbage-collection-algorithms/removing-unused-objects/sweep)。 348 | 349 | 350 | CMS的设计目标是避免在老年代垃圾收集时出现长时间的卡顿。主要通过两种手段来达成此目标。 351 | 352 | - 第一, 不对老年代进行整理, 而是使用空闲列表(free-lists)来管理内存空间的回收。 353 | - 第二, 在 **mark-and-sweep** (标记-清除) 阶段的大部分工作和应用线程一起并发执行。 354 | 355 | 也就是说, 在这些阶段并没有明显的应用线程暂停。但值得注意的是, 它仍然和应用线程争抢CPU时间。默认情况下, CMS 使用的并发线程数等于CPU内核数的 `1/4`。 356 | 357 | 358 | 通过以下选项来指定CMS垃圾收集器: 359 | 360 | 361 | java -XX:+UseConcMarkSweepGC com.mypackages.MyExecutableClass 362 | 363 | 364 | 如果服务器是多核CPU，并且主要调优目标是降低延迟, 那么使用CMS是个很明智的选择. 减少每一次GC停顿的时间,会直接影响到终端用户对系统的体验, 用户会认为系统非常灵敏。 因为多数时候都有部分CPU资源被GC消耗, 所以在CPU资源受限的情况下,CMS会比并行GC的吞吐量差一些。 365 | 366 | 367 | 和前面的GC算法一样, 我们先来看看CMS算法在实际应用中的GC日志, 其中包括一次 minor GC, 以及一次 major GC 停顿: 368 | 369 | 370 | 2015-05-26T16:23:07.219-0200: 64.322: [GC (Allocation Failure) 64.322: 371 | [ParNew: 613404K->68068K(613440K), 0.1020465 secs] 372 | 10885349K->10880154K(12514816K), 0.1021309 secs] 373 | [Times: user=0.78 sys=0.01, real=0.11 secs] 374 | 2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) 375 | [1 CMS-initial-mark: 10812086K(11901376K)] 376 | 10887844K(12514816K), 0.0001997 secs] 377 | [Times: user=0.00 sys=0.00, real=0.00 secs] 378 | 2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start] 379 | 2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] 380 | [Times: user=0.07 sys=0.00, real=0.03 secs] 381 | 2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start] 382 | 2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] 383 | [Times: user=0.02 sys=0.00, real=0.02 secs] 384 | 2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start] 385 | 2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] 386 | [Times: user=0.20 sys=0.00, real=1.07 secs] 387 | 2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) 388 | [YG occupancy: 387920 K (613440 K)] 389 | 65.550: [Rescan (parallel) , 0.0085125 secs] 390 | 65.559: [weak refs processing, 0.0000243 secs] 391 | 65.559: [class unloading, 0.0013120 secs] 392 | 65.560: [scrub symbol table, 0.0008345 secs] 393 | 65.561: [scrub string table, 0.0001759 secs] 394 | [1 CMS-remark: 10812086K(11901376K)] 395 | 11200006K(12514816K), 0.0110730 secs] 396 | [Times: user=0.06 sys=0.00, real=0.01 secs] 397 | 2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start] 398 | 2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] 399 | [Times: user=0.03 sys=0.00, real=0.03 secs] 400 | 2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start] 401 | 2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] 402 | [Times: user=0.01 sys=0.00, real=0.01 secs] 403 | 404 | 405 | 406 | ### Minor GC(小型GC) 407 | 408 | 409 | 日志中的第一次GC事件是清理年轻代的小型GC(Minor GC)。让我们来分析 CMS 垃圾收集器的行为: 410 | 411 | 412 | > `2015-05-26T16:23:07.219-0200`: `64.322`:[`GC`(`Allocation Failure`) 64.322:
413 | > [`ParNew`: `613404K->68068K``(613440K) `, `0.1020465 secs`]
414 | > `10885349K->10880154K ``(12514816K)`, `0.1021309 secs`]
415 | > `[Times: user=0.78 sys=0.01, real=0.11 secs]` 416 | 417 |
418 | 419 | > 420 | > 1. `2015-05-26T16:23:07.219-0200` – GC事件开始的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 421 | > 2. `64.322` – GC事件开始时,相对于JVM启动时的间隔时间,单位是秒。 422 | > 3. `GC` – 用来区分 Minor GC 还是 Full GC 的标志。`GC`表明这是一次**小型GC**(Minor GC) 423 | > 4. `Allocation Failure` – 触发垃圾收集的原因。本次GC事件, 是由于年轻代中没有适当的空间存放新的数据结构引起的。 424 | > 5. `ParNew` – 垃圾收集器的名称。这个名字表示的是在年轻代中使用的: 并行的 标记-复制(mark-copy), 全线暂停(STW)垃圾收集器, 专门设计了用来配合老年代使用的 Concurrent Mark & Sweep 垃圾收集器。 425 | > 6. `613404K->68068K` – 在垃圾收集之前和之后的年轻代使用量。 426 | > 7. `(613440K) ` – 年轻代的总大小。 427 | > 8. `0.1020465 secs` – 垃圾收集器在 w/o final cleanup 阶段消耗的时间 428 | > 9. `10885349K->10880154K ` – 在垃圾收集之前和之后堆内存的使用情况。 429 | > 10. `(12514816K)` – 可用堆的总大小。 430 | > 11. `0.1021309 secs` – 垃圾收集器在标记和复制年轻代存活对象时所消耗的时间。包括和ConcurrentMarkSweep收集器的通信开销, 提升存活时间达标的对象到老年代,以及垃圾收集后期的一些最终清理。 431 | > 12. `[Times: user=0.78 sys=0.01, real=0.11 secs]` – GC事件的持续时间, 通过三个部分来衡量: 432 | - user – 在此次垃圾回收过程中, 由GC线程所消耗的总的CPU时间。 433 | - sys – GC过程中中操作系统调用和系统等待事件所消耗的时间。 434 | - real – 应用程序暂停的时间。在并行GC(Parallel GC)中, 这个数字约等于: (user time + system time)/GC线程数。 这里使用的是8个线程。 请注意,总是有固定比例的处理过程是不能并行化的。 435 | 436 | 437 | 从上面的日志可以看出,在GC之前总的堆内存使用量为 **10,885,349K**, 年轻代的使用量为 **613,404K**。这意味着老年代使用量等于 **10,271,945K**。GC之后,年轻代的使用量减少了 545,336K, 而总的堆内存使用只下降了 **5,195K**。可以算出有 **540,141K** 的对象从年轻代提升到老年代。 438 | 439 | 440 | ![](04_05_ParallelGC-in-Young-Generation-Java.png) 441 | 442 | 443 | ### Full GC(完全GC) 444 | 445 | 446 | 现在, 我们已经熟悉了如何解读GC日志, 接下来将介绍一种完全不同的日志格式。下面这一段很长很长的日志, 就是CMS对老年代进行垃圾收集时输出的各阶段日志。为了简洁,我们对这些阶段逐个介绍。 首先来看CMS收集器整个GC事件的日志: 447 | 448 | 449 | 2015-05-26T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) 450 | [1 CMS-initial-mark: 10812086K(11901376K)] 451 | 10887844K(12514816K), 0.0001997 secs] 452 | [Times: user=0.00 sys=0.00, real=0.00 secs] 453 | 2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start] 454 | 2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] 455 | [Times: user=0.07 sys=0.00, real=0.03 secs] 456 | 2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start] 457 | 2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] 458 | [Times: user=0.02 sys=0.00, real=0.02 secs] 459 | 2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start] 460 | 2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] 461 | [Times: user=0.20 sys=0.00, real=1.07 secs] 462 | 2015-05-26T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) 463 | [YG occupancy: 387920 K (613440 K)] 464 | 65.550: [Rescan (parallel) , 0.0085125 secs] 465 | 65.559: [weak refs processing, 0.0000243 secs] 466 | 65.559: [class unloading, 0.0013120 secs] 467 | 65.560: [scrub symbol table, 0.0008345 secs] 468 | 65.561: [scrub string table, 0.0001759 secs] 469 | [1 CMS-remark: 10812086K(11901376K)] 470 | 11200006K(12514816K), 0.0110730 secs] 471 | [Times: user=0.06 sys=0.00, real=0.01 secs] 472 | 2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start] 473 | 2015-05-26T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] 474 | [Times: user=0.03 sys=0.00, real=0.03 secs] 475 | 2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start] 476 | 2015-05-26T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] 477 | [Times: user=0.01 sys=0.00, real=0.01 secs] 478 | 479 | 480 | 只是要记住 —— 在实际情况下, 进行老年代的并发回收时, 可能会伴随着多次年轻代的小型GC. 在这种情况下, 大型GC的日志中就会掺杂着多次小型GC事件, 像前面所介绍的一样。 481 | 482 | 483 | **阶段 1: Initial Mark(初始标记)**. 这是第一次STW事件。 此阶段的目标是标记老年代中所有存活的对象, 包括 GC ROOR 的直接引用, 以及由年轻代中存活对象所引用的对象。 后者也非常重要, 因为老年代是独立进行回收的。 484 | 485 | 486 | ![](04_06_g1-06.png) 487 | 488 | 489 | >`2015-05-26T16:23:07.321-0200: 64.42`1: [GC (`CMS Initial Mark`1
490 | >[1 CMS-initial-mark: `10812086K`1`(11901376K)`1] `10887844K`1`(12514816K)`1,
491 | > `0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]`1 492 | 493 |
494 | 495 | > 496 | > 1. `2015-05-26T16:23:07.321-0200: 64.42` – GC事件开始的时间. 其中 `-0200` 是时区,而中国所在的东8区为 +0800。 而 **64.42** 是相对于JVM启动的时间。 下面的其他阶段也是一样,所以就不再重复介绍。 497 | > 2. `CMS Initial Mark` – 垃圾回收的阶段名称为 “Initial Mark”。 标记所有的 GC Root。 498 | > 3. `10812086K` – 老年代的当前使用量。 499 | > 4. `(11901376K)` – 老年代中可用内存总量。 500 | > 5. `10887844K` – 当前堆内存的使用量。 501 | > 6. `(12514816K)` – 可用堆的总大小。 502 | > 7. `0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]` – 此次暂停的持续时间, 以 user, system 和 real time 3个部分进行衡量。 503 | 504 | 505 | **阶段 2: Concurrent Mark(并发标记).** 在此阶段, 垃圾收集器遍历老年代, 标记所有的存活对象, 从前一阶段 “Initial Mark” 找到的 root 根开始算起。 顾名思义, “并发标记”阶段, 就是与应用程序同时运行,不用暂停的阶段。 请注意, 并非所有老年代中存活的对象都在此阶段被标记, 因为在标记过程中对象的引用关系还在发生变化。 506 | 507 | 508 | ![](04_07_g1-07.png) 509 | 510 | 511 | 在上面的示意图中, “Current object” 旁边的一个引用被标记线程并发删除了。 512 | 513 | 514 | >2015-05-26T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
515 | >2015-05-26T16:23:07.357-0200: 64.460: [`CMS-concurrent-mark`1: `035/0.035 secs`1]
516 | >`[Times: user=0.07 sys=0.00, real=0.03 secs]`1
517 | 518 |
519 | 520 | > 521 | > 1. `CMS-concurrent-mark` – 并发标记("Concurrent Mark") 是CMS垃圾收集中的一个阶段, 遍历老年代并标记所有的存活对象。 522 | > 2. `035/0.035 secs` – 此阶段的持续时间, 分别是运行时间和相应的实际时间。 523 | > 3. `[Times: user=0.07 sys=0.00, real=0.03 secs]` – `Times` 这部分对并发阶段来说没多少意义, 因为是从并发标记开始时计算的,而这段时间内不仅并发标记在运行,程序也在运行 524 | 525 | 526 | **阶段 3: Concurrent Preclean(并发预清理).** 此阶段同样是与应用线程并行执行的, 不需要停止应用线程。 因为前一阶段是与程序并发进行的,可能有一些引用已经改变。如果在并发标记过程中发生了引用关系变化,JVM会(通过“Card”)将发生了改变的区域标记为“脏”区(这就是所谓的[卡片标记,Card Marking](http://psy-lob-saw.blogspot.com.ee/2014/10/the-jvm-write-barrier-card-marking.html))。 527 | 528 | 529 | ![](04_08_g1-08.png) 530 | 531 | 532 | 在预清理阶段,这些脏对象会被统计出来,从他们可达的对象也被标记下来。此阶段完成后, 用以标记的 card 也就被清空了。 533 | 534 | 535 | ![](04_09_g1-09.png) 536 | 537 | 538 | 此外, 本阶段也会执行一些必要的细节处理, 并为 Final Remark 阶段做一些准备工作。 539 | 540 | 541 | > 542 | >2015-05-26T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start] 543 | > 544 | >2015-05-26T16:23:07.373-0200: 64.476: [`CMS-concurrent-preclean`: `0.016/0.016 secs`] `[Times: user=0.02 sys=0.00, real=0.02 secs]` 545 | 546 | 547 |
548 | 549 | > 550 | > 1. `CMS-concurrent-preclean` – 并发预清理阶段, 统计此前的标记阶段中发生了改变的对象。 551 | > 2. `0.016/0.016 secs` – 此阶段的持续时间, 分别是运行时间和对应的实际时间。 552 | > 3. `[Times: user=0.02 sys=0.00, real=0.02 secs]` – Times 这部分对并发阶段来说没多少意义, 因为是从并发标记开始时计算的,而这段时间内不仅GC的并发标记在运行,程序也在运行。 553 | 554 | 555 | **阶段 4: Concurrent Abortable Preclean(并发可取消的预清理).** 此阶段也不停止应用线程. 本阶段尝试在 STW 的 Final Remark 之前尽可能地多做一些工作。本阶段的具体时间取决于多种因素, 因为它循环做同样的事情,直到满足某个退出条件( 如迭代次数, 有用工作量, 消耗的系统时间,等等)。 556 | 557 | 558 | > 559 | >2015-05-26T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start] 560 | > 561 | >2015-05-26T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean1: 0.167/1.074 secs2][Times: user=0.20 sys=0.00, real=1.07 secs]3 562 | 563 | 564 |
565 | 566 | > 567 | > 1. `CMS-concurrent-abortable-preclean` – 此阶段的名称: “Concurrent Abortable Preclean”。 568 | > 2. `0.167/1.074 secs` – 此阶段的持续时间, 运行时间和对应的实际时间。有趣的是, 用户时间明显比时钟时间要小很多。通常情况下我们看到的都是时钟时间小于用户时间, 这意味着因为有一些并行工作, 所以运行时间才会小于使用的CPU时间。这里只进行了少量的工作 — 0.167秒的CPU时间,GC线程经历了很多系统等待。从本质上讲,GC线程试图在必须执行 STW暂停之前等待尽可能长的时间。默认条件下,此阶段可以持续最多5秒钟。 569 | 570 | > 1. `[Times: user=0.20 sys=0.00, real=1.07 secs]` – “Times” 这部分对并发阶段来说没多少意义, 因为是从并发标记开始时计算的,而这段时间内不仅GC的并发标记线程在运行,程序也在运行 571 | 572 | 573 | 此阶段可能显著影响STW停顿的持续时间, 并且有许多重要的[配置选项](https://blogs.oracle.com/jonthecollector/entry/did_you_know)和失败模式。 574 | 575 | 576 | **阶段 5: Final Remark(最终标记).** 这是此次GC事件中第二次(也是最后一次)STW阶段。本阶段的目标是完成老年代中所有存活对象的标记. 因为之前的 preclean 阶段是并发的, 有可能无法跟上应用程序的变化速度。所以需要 STW暂停来处理复杂情况。 577 | 578 | 579 | 通常CMS会尝试在年轻代尽可能空的情况运行 final remark 阶段, 以免接连多次发生 STW 事件。 580 | 581 | 582 | 看起来稍微比之前的阶段要复杂一些: 583 | 584 | 585 | > `2015-05-26T16:23:08.447-0200: 65.550`: [GC (`CMS Final Remark`) [`YG occupancy: 387920 K (613440 K)`] 586 | > 65.550: `[Rescan (parallel) , 0.0085125 secs]` 65.559: [`weak refs processing, 0.0000243 secs]65.559`: [`class unloading, 0.0013120 secs]65.560`: [`scrub string table, 0.0001759 secs`] 587 | > [1 CMS-remark: `10812086K(11901376K)`] `11200006K(12514816K) `,`0.0110730 secs`] `[Times: user=0.06 sys=0.00, real=0.01 secs]` 588 | 589 |
590 | 591 | > 592 | > 1. `2015-05-26T16:23:08.447-0200: 65.550` – GC事件开始的时间. 包括时钟时间,以及相对于JVM启动的时间. 其中`-0200`表示西二时区,而中国所在的东8区为 `+0800`。 593 | > 2. `CMS Final Remark` – 此阶段的名称为 “Final Remark”, 标记老年代中所有存活的对象，包括在此前的并发标记过程中创建/修改的引用。 594 | > 3. `YG occupancy: 387920 K (613440 K)` – 当前年轻代的使用量和总容量。 595 | > 4. `[Rescan (parallel) , 0.0085125 secs]` – 在程序暂停时重新进行扫描(Rescan),以完成存活对象的标记。此时 rescan 是并行执行的,消耗的时间为 **0.0085125秒**。 596 | > 5. `weak refs processing, 0.0000243 secs]65.559` – 处理弱引用的第一个子阶段(sub-phases)。 显示的是持续时间和开始时间戳。 597 | > 6. `class unloading, 0.0013120 secs]65.560` – 第二个子阶段, 卸载不使用的类。 显示的是持续时间和开始的时间戳。 598 | > 7. `scrub string table, 0.0001759 secs` – 最后一个子阶段, 清理持有class级别 metadata 的符号表(symbol tables),以及内部化字符串对应的 string tables。当然也显示了暂停的时钟时间。 599 | > 8. `10812086K(11901376K)` – 此阶段完成后老年代的使用量和总容量 600 | > 9. `11200006K(12514816K) ` – 此阶段完成后整个堆内存的使用量和总容量 601 | > 10. `0.0110730 secs` – 此阶段的持续时间。 602 | > 11. `[Times: user=0.06 sys=0.00, real=0.01 secs]` – GC事件的持续时间, 通过不同的类别来衡量: user, system and real time。 603 | 604 | 605 | 在5个标记阶段完成之后, 老年代中所有的存活对象都被标记了, 现在GC将清除所有不使用的对象来回收老年代空间: 606 | 607 | 608 | **阶段 6: Concurrent Sweep(并发清除).** 此阶段与应用程序并发执行,不需要STW停顿。目的是删除未使用的对象,并收回他们占用的空间。 609 | 610 | 611 | ![](04_10_g1-10.png) 612 | 613 | 614 | > 615 | >2015-05-26T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start] 2015-05-26T16:23:08.485-0200: 65.588: [`CMS-concurrent-sweep`: `0.027/0.027 secs`] `[Times: user=0.03 sys=0.00, real=0.03 secs] ` 616 | 617 |
618 | 619 | > 620 | > 1. `CMS-concurrent-sweep` – 此阶段的名称, “Concurrent Sweep”, 清除未被标记、不再使用的对象以释放内存空间。 621 | > 2. `0.027/0.027 secs` – 此阶段的持续时间, 分别是运行时间和实际时间 622 | > 3. `[Times: user=0.03 sys=0.00, real=0.03 secs] ` – “Times”部分对并发阶段来说没有多少意义, 因为是从并发标记开始时计算的,而这段时间内不仅是并发标记在运行,程序也在运行。 623 | 624 | 625 | **阶段 7: Concurrent Reset(并发重置).** 此阶段与应用程序并发执行,重置CMS算法相关的内部数据, 为下一次GC循环做准备。 626 | 627 | 628 | > 629 | >2015-05-26T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start] 2015-05-26T16:23:08.497-0200: 65.601: [`CMS-concurrent-reset`: `0.012/0.012 secs`] `[Times: user=0.01 sys=0.00, real=0.01 secs]` 630 | 631 |
632 | 633 | > 634 | > 1. `CMS-concurrent-reset` – 此阶段的名称, “Concurrent Reset”, 重置CMS算法的内部数据结构, 为下一次GC循环做准备。 635 | > 2. `0.012/0.012 secs` – 此阶段的持续时间, 分别是运行时间和对应的实际时间 636 | > 3. `[Times: user=0.01 sys=0.00, real=0.01 secs]` – “Times”部分对并发阶段来说没多少意义, 因为是从并发标记开始时计算的,而这段时间内不仅GC线程在运行,程序也在运行。 637 | 638 | 639 | 总之, CMS垃圾收集器在减少停顿时间上做了很多给力的工作, 大量的并发线程执行的工作并不需要暂停应用线程。 当然, CMS也有一些缺点,其中最大的问题就是老年代内存碎片问题, 在某些情况下GC会造成不可预测的暂停时间, 特别是堆内存较大的情况下。 640 | 641 | 642 | ## G1 – Garbage First(垃圾优先算法) 643 | 644 | 645 | G1最主要的设计目标是: 将STW停顿的时间和分布变成可预期以及可配置的。事实上, G1是一款软实时垃圾收集器, 也就是说可以为其设置某项特定的性能指标. 可以指定: 在任意 `xx` 毫秒的时间范围内, STW停顿不得超过 `x` 毫秒。 如: 任意1秒暂停时间不得超过5毫秒. Garbage-First GC 会尽力达成这个目标(有很大的概率会满足, 但并不完全确定,具体是多少将是硬实时的[hard real-time])。 646 | 647 | 648 | 为了达成这项指标, G1 有一些独特的实现。首先, 堆不再分成连续的年轻代和老年代空间。而是划分为多个(通常是2048个)可以存放对象的 **小堆区(smaller heap regions)**。每个小堆区都可能是 Eden区, Survivor区或者Old区. 在逻辑上, 所有的Eden区和Survivor区合起来就是年轻代, 所有的Old区拼在一起那就是老年代: 649 | 650 | 651 | ![](04_11_g1-011.png) 652 | 653 | 654 | 这样的划分使得 GC不必每次都去收集整个堆空间, 而是以增量的方式来处理: 每次只处理一部分小堆区,称为此次的回收集(collection set). 每次暂停都会收集所有年轻代的小堆区, 但可能只包含一部分老年代小堆区: 655 | 656 | 657 | ![](04_12_g1-02.png) 658 | 659 | 660 | G1的另一项创新, 是在并发阶段估算每个小堆区存活对象的总数。用来构建回收集(collection set)的原则是: **垃圾最多的小堆区会被优先收集**。这也是G1名称的由来: garbage-first。 661 | 662 | 663 | 要启用G1收集器, 使用的命令行参数为: 664 | 665 | 666 | java -XX:+UseG1GC com.mypackages.MyExecutableClass 667 | 668 | 669 | ### Evacuation Pause: Fully Young(转移暂停:纯年轻代模式) 670 | 671 | 672 | 在应用程序刚启动时, G1还未执行过(not-yet-executed)并发阶段, 也就没有获得任何额外的信息, 处于初始的 fully-young 模式. 在年轻代空间用满之后, 应用线程被暂停, 年轻代堆区中的存活对象被复制到存活区, 如果还没有存活区,则选择任意一部分空闲的小堆区用作存活区。 673 | 674 | 675 | 复制的过程称为转移(Evacuation), 这和前面讲过的年轻代收集器基本上是一样的工作原理。转移暂停的日志信息很长,为简单起见, 我们去除了一些不重要的信息. 在并发阶段之后我们会进行详细的讲解。此外, 由于日志记录很多, 所以并行阶段和“其他”阶段的日志将拆分为多个部分来进行讲解: 676 | 677 | 678 | > `0.134: [GC pause (G1 Evacuation Pause) (young), 0.0144119 secs]`
679 | > `[Parallel Time: 13.9 ms, GC Workers: 8]`
680 | > `…`
681 | > `[Code Root Fixup: 0.0 ms]`
682 | > `[Code Root Purge: 0.0 ms]`
683 | > [Clear CT: 0.1 ms]
684 | > `[Other: 0.4 ms]` 685 | > `…`
686 | > `[Eden: 24.0M(24.0M)->0.0B(13.0M) ` `Survivors: 0.0B->3072.0K ` `Heap: 24.0M(256.0M)->21.9M(256.0M)]` 687 | > `[Times: user=0.04 sys=0.04, real=0.02 secs] ` 688 | 689 |
690 | 691 | 692 | > 693 | > 1. `0.134: [GC pause (G1 Evacuation Pause) (young), 0.0144119 secs]` – G1转移暂停,只清理年轻代空间。暂停在JVM启动之后 134 ms 开始, 持续的系统时间为 **0.0144秒** 。 694 | > 2. `[Parallel Time: 13.9 ms, GC Workers: 8]` – 表明后面的活动由8个 Worker 线程并行执行, 消耗时间为13.9毫秒(real time)。 695 | > 3. `…` – 为阅读方便, 省略了部分内容,请参考后文。 696 | > 4. `[Code Root Fixup: 0.0 ms]` – 释放用于管理并行活动的内部数据。一般都接近于零。这是串行执行的过程。 697 | > 5. `[Code Root Purge: 0.0 ms]` – 清理其他部分数据, 也是非常快的, 但如非必要则几乎等于零。这是串行执行的过程。 698 | > 6. `[Other: 0.4 ms]` – 其他活动消耗的时间, 其中有很多是并行执行的。 699 | > 7. `…` – 请参考后文。 700 | > 8. `[Eden: 24.0M(24.0M)->0.0B(13.0M) ` – 暂停之前和暂停之后, Eden 区的使用量/总容量。 701 | > 9. `Survivors: 0.0B->3072.0K ` – 暂停之前和暂停之后, 存活区的使用量。 702 | > 10. `Heap: 24.0M(256.0M)->21.9M(256.0M)]` – 暂停之前和暂停之后, 整个堆内存的使用量与总容量。 703 | > 11. `[Times: user=0.04 sys=0.04, real=0.02 secs] ` – GC事件的持续时间, 通过三个部分来衡量: 704 | - user – 在此次垃圾回收过程中, 由GC线程所消耗的总的CPU时间。 705 | - sys – GC过程中, 系统调用和系统等待事件所消耗的时间。 706 | - real – 应用程序暂停的时间。在并行GC(Parallel GC)中, 这个数字约等于: (user time + system time)/GC线程数。 这里使用的是8个线程。 请注意,总是有一定比例的处理过程是不能并行化的。 707 | 708 | 709 | > 说明: 系统时间(wall clock time, elapsed time), 是指一段程序从运行到终止，系统时钟走过的时间。一般来说，系统时间都是要大于CPU时间 710 | 711 | 712 | 最繁重的GC任务由多个专用的 worker 线程来执行。下面的日志描述了他们的行为: 713 | 714 | 715 | > `[Parallel Time: 13.9 ms, GC Workers: 8]`
716 | > `[GC Worker Start (ms)`: Min: 134.0, Avg: 134.1, Max: 134.1, Diff: 0.1]
717 | > `[Ext Root Scanning (ms)`: Min: 0.1, Avg: 0.2, Max: 0.3, Diff: 0.2, Sum: 1.2]
[Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
718 | > [Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0]
719 | > [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
720 | > `[Code Root Scanning (ms)`: Min: 0.0, Avg: 0.0, Max: 0.2, Diff: 0.2, Sum: 0.2]
721 | > `[Object Copy (ms)`: Min: 10.8, Avg: 12.1, Max: 12.6, Diff: 1.9, Sum: 96.5]
722 | > `[Termination (ms)`: Min: 0.8, Avg: 1.5, Max: 2.8, Diff: 1.9, Sum: 12.2]
723 | > `[Termination Attempts`: Min: 173, Avg: 293.2, Max: 362, Diff: 189, Sum: 2346]
724 | > `[GC Worker Other (ms)`: Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
725 | > `GC Worker Total (ms)`: Min: 13.7, Avg: 13.8, Max: 13.8, Diff: 0.1, Sum: 110.2]
726 | > `[GC Worker End (ms)`: Min: 147.8, Avg: 147.8, Max: 147.8, Diff: 0.0]
727 | 728 |
729 | 730 | > 731 | > 1. `[Parallel Time: 13.9 ms, GC Workers: 8]` – 表明下列活动由8个线程并行执行,消耗的时间为13.9毫秒(real time)。 732 | > 2. `[GC Worker Start (ms)` – GC的worker线程开始启动时,相对于 pause 开始的时间戳。如果 `Min` 和 `Max` 差别很大,则表明本机其他进程所使用的线程数量过多, 挤占了GC的CPU时间。 733 | > 3. `[Ext Root Scanning (ms)` – 用了多长时间来扫描堆外(non-heap)的root, 如 classloaders, JNI引用, JVM的系统root等。后面显示了运行时间, “Sum” 指的是CPU时间。 734 | > 4. `[Code Root Scanning (ms)` – 用了多长时间来扫描实际代码中的 root: 例如局部变量等等(local vars)。 735 | > 5. `[Object Copy (ms)` – 用了多长时间来拷贝收集区内的存活对象。 736 | > 6. `[Termination (ms)` – GC的worker线程用了多长时间来确保自身可以安全地停止, 这段时间什么也不用做, stop 之后该线程就终止运行了。 737 | > 7. `[Termination Attempts` – GC的worker 线程尝试多少次 try 和 teminate。如果worker发现还有一些任务没处理完,则这一次尝试就是失败的, 暂时还不能终止。 738 | > 8. `[GC Worker Other (ms)` – 一些琐碎的小活动,在GC日志中不值得单独列出来。 739 | > 9. `GC Worker Total (ms)` – GC的worker 线程的工作时间总计。 740 | > 10. `[GC Worker End (ms)` – GC的worker 线程完成作业的时间戳。通常来说这部分数字应该大致相等, 否则就说明有太多的线程被挂起, 很可能是因为[坏邻居效应(noisy neighbor)](https://github.com/cncounter/translation/blob/master/tiemao_2016/45_noisy_neighbors/noisy_neighbor_cloud%20_performance.md) 所导致的。 741 | 742 | 743 | 此外,在转移暂停期间,还有一些琐碎执行的小活动。这里我们只介绍其中的一部分, 其余的会在后面进行讨论。 744 | 745 | 746 | > `[Other: 0.4 ms]`
747 | > [Choose CSet: 0.0 ms]
748 | > `[Ref Proc: 0.2 ms]`
749 | > `[Ref Enq: 0.0 ms]`
750 | > [Redirty Cards: 0.1 ms]
751 | > [Humongous Register: 0.0 ms]
752 | > [Humongous Reclaim: 0.0 ms]
753 | > `[Free CSet: 0.0 ms]`
754 | 755 |
756 | 757 | > 758 | > 1. `[Other: 0.4 ms]` – 其他活动消耗的时间, 其中有很多也是并行执行的。 759 | > 2. `[Ref Proc: 0.2 ms]` – 处理非强引用(non-strong)的时间: 进行清理或者决定是否需要清理。 760 | > 3. `[Ref Enq: 0.0 ms]` – 用来将剩下的 non-strong 引用排列到合适的 **ReferenceQueue**中。 761 | > 4. `[Free CSet: 0.0 ms]` – 将回收集中被释放的小堆归还所消耗的时间, 以便他们能用来分配新的对象。 762 | 763 | 764 | 765 | ### Concurrent Marking(并发标记) 766 | 767 | 768 | G1收集器的很多概念建立在CMS的基础上,所以下面的内容需要你对CMS有一定的理解. 虽然也有很多地方不同, 但并发标记的目标基本上是一样的. G1的并发标记通过 **Snapshot-At-The-Beginning(开始时快照)** 的方式, 在标记阶段开始时记下所有的存活对象。即使在标记的同时又有一些变成了垃圾. 通过对象是存活信息, 可以构建出每个小堆区的存活状态, 以便回收集能高效地进行选择。 769 | 770 | 771 | 这些信息在接下来的阶段会用来执行老年代区域的垃圾收集。在两种情况下是完全地并发执行的： 一、如果在标记阶段确定某个小堆区只包含垃圾; 二、在STW转移暂停期间, 同时包含垃圾和存活对象的老年代小堆区。 772 | 773 | 774 | 当堆内存的总体使用比例达到一定数值时,就会触发并发标记。默认值为 `45%`, 但也可以通过JVM参数 **`InitiatingHeapOccupancyPercent`** 来设置。和CMS一样, G1的并发标记也是由多个阶段组成, 其中一些是完全并发的, 还有一些阶段需要暂停应用线程。 775 | 776 | 777 | **阶段 1: Initial Mark(初始标记)。** 此阶段标记所有从GC root 直接可达的对象。在CMS中需要一次STW暂停, 但G1里面通常是在转移暂停的同时处理这些事情, 所以它的开销是很小的. 可以在 Evacuation Pause 日志中的第一行看到(initial-mark)暂停: 778 | 779 | 780 | 1.631: [GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0062656 secs] 781 | 782 | 783 | **阶段 2: Root Region Scan(Root区扫描).** 此阶段标记所有从 "根区域" 可达的存活对象。 根区域包括: 非空的区域, 以及在标记过程中不得不收集的区域。因为在并发标记的过程中迁移对象会造成很多麻烦, 所以此阶段必须在下一次转移暂停之前完成。如果必须启动转移暂停, 则会先要求根区域扫描中止, 等它完成才能继续扫描. 在当前版本的实现中, 根区域是存活的小堆区: y包括下一次转移暂停中肯定会被清理的那部分年轻代小堆区。 784 | 785 | 786 | 1.362: [GC concurrent-root-region-scan-start] 787 | 1.364: [GC concurrent-root-region-scan-end, 0.0028513 secs] 788 | 789 | 790 | **阶段 3: Concurrent Mark(并发标记).** 此阶段非常类似于CMS: 它只是遍历对象图, 并在一个特殊的位图中标记能访问到的对象. 为了确保标记开始时的快照准确性, 所有应用线程并发对对象图执行的引用更新,G1 要求放弃前面阶段为了标记目的而引用的过时引用。 791 | 792 | 793 | 这是通过使用 `Pre-Write` 屏障来实现的,(不要和之后介绍的 `Post-Write ` 混淆, 也不要和多线程开发中的内存屏障(memory barriers)相混淆)。Pre-Write屏障的作用是: G1在进行并发标记时, 如果程序将对象的某个属性做了变更, 就会在 log buffers 中存储之前的引用。 由并发标记线程负责处理。 794 | 795 | 796 | 1.364: [GC concurrent-mark-start] 797 | 1.645: [GC co ncurrent-mark-end, 0.2803470 secs] 798 | 799 | 800 | **阶段 4: Remark(再次标记).** 和CMS类似,这也是一次STW停顿,以完成标记过程。对于G1,它短暂地停止应用线程, 停止并发更新日志的写入, 处理其中的少量信息, 并标记所有在并发标记开始时未被标记的存活对象。这一阶段也执行某些额外的清理, 如引用处理(参见 Evacuation Pause log) 或者类卸载(class unloading)。 801 | 802 | 803 | 1.645: [GC remark 1.645: [Finalize Marking, 0.0009461 secs] 804 | 1.646: [GC ref-proc, 0.0000417 secs] 1.646: 805 | [Unloading, 0.0011301 secs], 0.0074056 secs] 806 | [Times: user=0.01 sys=0.00, real=0.01 secs] 807 | 808 | 809 | **阶段 5: Cleanup(清理).** 最后这个小阶段为即将到来的转移阶段做准备, 统计小堆区中所有存活的对象, 并将小堆区进行排序, 以提升GC的效率. 此阶段也为下一次标记执行所有必需的整理工作(house-keeping activities): 维护并发标记的内部状态。 810 | 811 | 812 | 最后要提醒的是, 所有不包含存活对象的小堆区在此阶段都被回收了。有一部分是并发的: 例如空堆区的回收,还有大部分的存活率计算, 此阶段也需要一个短暂的STW暂停, 以不受应用线程的影响来完成作业. 这种STW停顿的日志如下: 813 | 814 | 815 | 1.652: [GC cleanup 1213M->1213M(1885M), 0.0030492 secs] 816 | [Times: user=0.01 sys=0.00, real=0.00 secs] 817 | 818 | 819 | 如果发现某些小堆区中只包含垃圾, 则日志格式可能会有点不同, 如: 820 | ​ 821 | 1.872: [GC cleanup 1357M->173M(1996M), 0.0015664 secs] 822 | [Times: user=0.01 sys=0.00, real=0.01 secs] 823 | 1.874: [GC concurrent-cleanup-start] 824 | 1.876: [GC concurrent-cleanup-end, 0.0014846 secs] 825 | 826 | 827 | ### Evacuation Pause: Mixed (转移暂停: 混合模式) 828 | 829 | 830 | 能并发清理老年代中整个整个的小堆区是一种最优情形, 但有时候并不是这样。并发标记完成之后, G1将执行一次混合收集(mixed collection), 不只清理年轻代, 还将一部分老年代区域也加入到 collection set 中。 831 | 832 | 833 | 混合模式的转移暂停(Evacuation pause)不一定紧跟着并发标记阶段。有很多规则和历史数据会影响混合模式的启动时机。比如, 假若在老年代中可以并发地腾出很多的小堆区,就没有必要启动混合模式。 834 | 835 | 836 | 因此, 在并发标记与混合转移暂停之间, 很可能会存在多次 fully-young 转移暂停。 837 | 838 | 839 | 添加到回收集的老年代小堆区的具体数字及其顺序, 也是基于许多规则来判定的。 其中包括指定的软实时性能指标, 存活性,以及在并发标记期间收集的GC效率等数据, 外加一些可配置的JVM选项. 混合收集的过程, 很大程度上和前面的 fully-young gc 是一样的, 但这里我们还要介绍一个概念: remembered sets(历史记忆集)。 840 | 841 | 842 | Remembered sets (历史记忆集)是用来支持不同的小堆区进行独立回收的。例如,在收集A、B、C区时, 我们必须要知道是否有从D区或者E区指向其中的引用, 以确定他们的存活性. 但是遍历整个堆需要相当长的时间, 这就违背了增量收集的初衷, 因此必须采取某种优化手段. 其他GC算法有独立的 Card Table 来支持年轻代的垃圾收集一样, 而G1中使用的是 Remembered Sets。 843 | 844 | 845 | 如下图所示, 每个小堆区都有一个 **remembered set**, 列出了从外部指向本区的所有引用。这些引用将被视为附加的 GC root. 注意,在并发标记过程中,老年代中被确定为垃圾的对象会被忽略, 即使有外部引用指向他们: 因为在这种情况下引用者也是垃圾。 846 | 847 | 848 | ![](04_13_g1-03.png) 849 | 850 | 851 | 接下来的行为,和其他垃圾收集器一样: 多个GC线程并行地找出哪些是存活对象,确定哪些是垃圾: 852 | 853 | 854 | ![](04_14_g1-04.png) 855 | 856 | 857 | 最后, 存活对象被转移到存活区(survivor regions), 在必要时会创建新的小堆区。现在,空的小堆区被释放, 可用于存放新的对象了。 858 | 859 | 860 | ![](04_15_g1-05-v2.png) 861 | 862 | 863 | 为了维护 remembered set, 在程序运行的过程中, 只要写入某个字段,就会产生一个 Post-Write 屏障。如果生成的引用是跨区域的(cross-region),即从一个区指向另一个区, 就会在目标区的Remembered Set中,出现一个对应的条目。为了减少 Write Barrier 造成的开销, 将卡片放入Remembered Set 的过程是异步的, 而且经过了很多的优化. 总体上是这样: Write Barrier 把脏卡信息存放到本地缓冲区(local buffer), 有专门的GC线程负责收集, 并将相关信息传给被引用区的 remembered set。 864 | 865 | 866 | 混合模式下的日志, 和纯年轻代模式相比, 可以发现一些有趣的地方: 867 | 868 | 869 | > [`[Update RS (ms)`: Min: 0.7, Avg: 0.8, Max: 0.9, Diff: 0.2, Sum: 6.1]
870 | > `[Processed Buffers`: Min: 0, Avg: 2.2, Max: 5, Diff: 5, Sum: 18]
871 | > `[Scan RS (ms)`: Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.8]
872 | > `[Clear CT: 0.2 ms]`
873 | > `[Redirty Cards: 0.1 ms]` 874 | 875 |
876 | 877 | 878 | >
879 | > 1. `[Update RS (ms)` – 因为 Remembered Sets 是并发处理的,必须确保在实际的垃圾收集之前, 缓冲区中的 card 得到处理。如果card数量很多, 则GC并发线程的负载可能就会很高。可能的原因是, 修改的字段过多, 或者CPU资源受限。 880 | 881 | > 1. `[Processed Buffers` – 每个 worker 线程处理了多少个本地缓冲区(local buffer)。 882 | > 2. `[Scan RS (ms)` – 用了多长时间扫描来自RSet的引用。 883 | > 3. `[Clear CT: 0.2 ms]` – 清理 card table 中 cards 的时间。清理工作只是简单地删除“脏”状态, 此状态用来标识一个字段是否被更新的, 供Remembered Sets使用。 884 | > 4. `[Redirty Cards: 0.1 ms]` – 将 card table 中适当的位置标记为 dirty 所花费的时间。"适当的位置"是由GC本身执行的堆内存改变所决定的, 例如引用排队等。 885 | 886 | 887 | ### 总结 888 | 889 | 890 | 通过本节内容的学习, 你应该对G1垃圾收集器有了一定了解。当然, 为了简洁, 我们省略了很多实现细节， 例如如何处理[巨无霸对象(humongous objects)](https://plumbr.eu/handbook/gc-tuning-in-practice#humongous-allocations)。 综合来看, G1是HotSpot中最先进的**准产品级(production-ready)**垃圾收集器。重要的是, HotSpot 工程师的主要精力都放在不断改进G1上面, 在新的java版本中,将会带来新的功能和优化。 891 | 892 | 893 | 可以看到, G1 解决了 CMS 中的各种疑难问题, 包括暂停时间的可预测性, 并终结了堆内存的碎片化。对单业务延迟非常敏感的系统来说, 如果CPU资源不受限制,那么G1可以说是 HotSpot 中最好的选择, 特别是在最新版本的Java虚拟机中。当然,这种降低延迟的优化也不是没有代价的: 由于额外的写屏障(write barriers)和更积极的守护线程, G1的开销会更大。所以, 如果系统属于吞吐量优先型的, 又或者CPU持续占用100%, 而又不在乎单次GC的暂停时间, 那么CMS是更好的选择。 894 | 895 | 896 | > 总之: **G1适合大内存,需要低延迟的场景**。 897 | 898 | 899 | 选择正确的GC算法,唯一可行的方式就是去尝试,并找出不对劲的地方, 在下一章我们将给出一般指导原则。 900 | 901 | 902 | 注意,G1可能会成为Java 9的默认GC: [http://openjdk.java.net/jeps/248](http://openjdk.java.net/jeps/248) 903 | 904 | 905 | ## Shenandoah 的性能 906 | 907 | > **译注**: Shenandoah: 谢南多厄河; 情人渡,水手谣; --> 此款GC暂时没有标准的中文译名; 翻译为大水手垃圾收集器? 908 | 909 | 910 | 我们列出了HotSpot中可用的所有 "准生产级" 算法。还有一种还在实验室中的算法, 称为**超低延迟垃圾收集器(Ultra-Low-Pause-Time Garbage Collector)**. 它的设计目标是管理大型的多核服务器上,超大型的堆内存: 管理 100GB 及以上的堆容量, GC暂停时间小于 10ms。 当然,也是需要和吞吐量进行权衡的: 没有GC暂停的时候,算法的实现对吞吐量的性能损失不能超过10% 911 | 912 | 913 | 在新算法作为准产品级进行发布之前, 我们不准备去讨论具体的实现细节, 但它也构建在前面所提到的很多算法的基础上, 例如并发标记和增量收集。但其中有很多东西是不同的。它不再将堆内存划分成多个代, 而是只采用单个空间. 没错, Shenandoah 并不是一款分代垃圾收集器。这也就不再需要 card tables 和 remembered sets. 它还使用转发指针(forwarding pointers), 以及Brooks 风格的读屏障(Brooks style read barrier), 以允许对存活对象的并发复制, 从而减少GC暂停的次数和时间。 914 | 915 | 916 | 关于 Shenandoah 的更多信息,请参考博客: [https://rkennke.wordpress.com/](https://rkennke.wordpress.com/), JEP文档: [http://openjdk.java.net/jeps/189](http://openjdk.java.net/jeps/189), 或者Google搜索 "[Shenandoah GC](https://www.google.com.hk/search?q=Shenandoah+GC)"。 917 | 918 | 919 | 原文链接: [GC Algorithms: Implementations](https://plumbr.eu/handbook/garbage-collection-algorithms-implementations) 920 | 921 | 922 | -------------------------------------------------------------------------------- /05_01_assembly-line01-compact.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/05_01_assembly-line01-compact.jpg -------------------------------------------------------------------------------- /05_02_assembly-line02-compact.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/05_02_assembly-line02-compact.jpg -------------------------------------------------------------------------------- /05_GC_Tuning_Basics.md: -------------------------------------------------------------------------------- 1 | # 5. GC 调优(基础篇) 2 | 3 | 4 | > **说明**: 5 | > 6 | > **Capacity**: 性能,能力,系统容量; 文中翻译为"**系统容量**"; 意为硬件配置约束,参见下文。 7 | 8 | 9 | 10 | Tuning garbage collection is no different from any other performance-tuning activity. It is easy to fall into the trap of randomly tweaking one of the 200 GC-related JVM parameters or to start changing random parts of your application code. Instead, following a simple process will guarantee that you are actually moving towards the right target while being transparent about the progress: 11 | 12 | 13 | GC调优(Tuning Garbage Collection)和其他性能调优都是一样的原理。一般人可能会对 200 多个 GC相关的JVM参数一头雾水, 随机调整几个来看结果,又或者随便改变程序的一些代码。其实只要按照下面的步骤，就能保证你的调优方向正确: 14 | 15 | 1. State your performance goals 16 | 2. Run tests 17 | 3. Measure the results 18 | 4. Compare the results with the goals 19 | 5. If goals are not met, make a change and go back to running tests 20 | 21 |
22 | 23 | 1. 列出性能调优指标(State your performance goals) 24 | 2. 执行测试(Run tests) 25 | 3. 衡量结果(Measure the results) 26 | 4. 与目标进行对比(Compare the results with the goals) 27 | 5. 如果达不到指标, 修改配置参数, 然后继续测试(go back to running tests) 28 | 29 | 30 | 31 | 32 | 33 | So, as the first step we need to set clear performance goals in regards of Garbage Collection. The goals fall into three categories, which are common to all performance monitoring and management topics: 34 | 35 | 36 | 那么,第一步我们需要做的事情就是: 制定明确的GC性能指标。对所有性能监控和管理来说, 有三个维度是通用的: 37 | 38 | 39 | 40 | - Latency(延迟) 41 | - Throughput(吞吐量) 42 | - Capacity(系统容量) 43 | 44 | 45 | 46 | After explaining the concepts in general, we will demonstrate how to apply these goals in the context of Garbage Collection. If you are already familiar with the concepts of latency, throughput and capacity, you may decide to skip the next section. 47 | 48 | 49 | 我们先讲解基本概念,然后再演示在垃圾收集时如何使用这些指标。如果您已经很熟悉 延迟、吞吐量和系统容量等概念, 则可以决定跳过下一小节。 50 | 51 | 52 | ## 核心概念(Core Concepts) 53 | 54 | 55 | 56 | Let us start with an example from manufacturing by observing an assembly line in a factory. The line is assembling bikes from ready-made components. Bikes are built on this line in a sequential manner. Monitoring the line in action, we measure that it takes four hours to complete a bike from the moment the frame enters the line until the assembled bike leaves the line at the other end. 57 | 58 | 59 | 我们先观察一家工厂的装配流水线。在流水线上,将现成的组件按顺序通过,组装成自行车。通过实际观察, 我们发现从组件进入生产线，到另一端组装成自行车需要4个小时。 60 | 61 | 62 | 63 | ![](05_01_assembly-line01-compact.jpg) 64 | 65 | 66 | 67 | 68 | Continuing our observations we can also see that one bike is assembled after each minute, 24 hours a day, every day. Simplifying the example and ignoring maintenance windows, we can forecast that in **any given hour such an assembly line assembles 60 bikes**. 69 | 70 | 71 | 继续观察,我们还发现,此后每分钟就有1辆自行车完成组装, 每天24小时,一直如此。将示例简化并忽略维护窗口期后得出: **这条流水线每小时可以组装60辆自行车**。 72 | 73 | > **说明**: 时间窗口、窗口期，请类比车站卖票的窗口，是一段规定/限定做某件事的时间段。 74 | 75 | 76 | 77 | Equipped with these two measurements, we now possess crucial information about the current performance of the assembly line in regards of **latency** and **throughput**: 78 | 79 | 80 | 通过这两种测量方式, 现在就知道了生产线的相关性能信息： **延迟**与**吞吐量**: 81 | 82 | 83 | 84 | - Latency of the assembly line: 4 hours 85 | - Throughput of the assembly line: 60 bikes/hour 86 | 87 | 88 | - 生产线的延迟: **4小时** 89 | - 生产线的吞吐量: **60辆/小时** 90 | 91 | 92 | 93 | Notice that latency is measured in time units suitable for the task at hand – anything from nanoseconds to millennia can be a good choice. Throughput of a system is measured in completed operations per time unit. Operations can be anything relevant to the specific system. In this example the chosen time unit was hours and operations were the assembled bikes. 94 | 95 | 96 | 请注意, 衡量延迟的时间单位根据需要而确定 —— 从纳秒(nanosecond)到几千年(millennia)都可以。系统的吞吐量是每个单位时间内完成的操作。操作(Operations)一般是特定系统相关的东西。在本例中,选择的时间单位是小时, 操作就是自行车的组装。 97 | 98 | 99 | 100 | Having been equipped with the definitions of latency and throughput, let us carry out a performance tuning exercise in the very same factory. The demand for the bikes has been steady for a while and the assembly line has kept producing bikes with the latency of four hours and the throughput of 60 bikes/hour for months. Let us now imagine a situation where the sales team has been successful and the demand for the bikes suddenly doubles. Instead of the usual 60*24 = 1,440 bikes/day the customers demand twice as many. The performance of the factory is no longer satisfactory and something needs to be done. 101 | 102 | 103 | 掌握了延迟和吞吐量这两个概念之后, 让我们对这个工厂来进行调优实战吧。自行车的需求在一段时间内都很稳定, 生产线组装自行车需要四小时的延迟, 而吞吐量几个月以来都是60辆/小时。现在假设某个销售团队业绩斐然, 自行车的需求量突然增加了1倍。客户的需求不再是 60 * 24 = 1440辆/天,而是变为了两倍。老板对工厂的产能不再满意，需要调整某些地方来提升性能。 104 | 105 | 106 | 107 | 108 | The factory manager seemingly correctly concludes that the latency of the system is not a concern – instead he should focus on the total number of bikes produced per day. Coming to this conclusion and assuming he is well funded, the hypothetical manager would immediately take the necessary steps to improve throughput by adding capacity. 109 | 110 | 111 | 管理者看起来很容易得出正确的判断, 系统的延迟没法子进行处理 —— 他应该关注自行车每天的生产总数。得出这个结论以后, 假如工厂资金充足, 那么老板应该立即采取措施, 改善吞吐量以增加产能。 112 | 113 | 114 | 115 | As a result we would now be observing not one but two identical assembly lines in the same factory. Both of these assembly lines would be assembling the very same bike every minute of every day. By doing this, our imaginary factory has doubled the number of bikes produced per day. Instead of the 1,440 bikes the factory is now capable of shipping 2,880 bikes each day. It is important to note that we have not reduced the time to complete an individual bike by even a millisecond – it still takes four hours to complete a bike from start to finish. 116 | 117 | 118 | 因此我们会看到, 这家工厂会有两条相同的生产线。这两条生产线每分钟都能各自组装出一辆成品自行车。这样,我们可以想象到，每天生产的自行车数量会增加一倍。不是1440辆, 而是2880辆/天。要注意的是, 我们不需要减少自行车的装配时间 —— 从开始到结束仍然需要四个小时。 119 | 120 | 121 | 122 | ![](05_02_assembly-line02-compact.jpg) 123 | 124 | 125 | 126 | In the example above a performance optimization task was carried out, coincidentally impacting both throughput and capacity. As in any good example we started by measuring the system’s current performance, then set a new target and optimized the system only in the aspects required to meet the target. 127 | 128 | 129 | 巧合的是，在上面的例子中进行的性能优化任务,同时影响了吞吐量和产能。一般来说，我们会先测量系统的当前性能,然后再设定新目标, 只优化系统的一个方面来满足性能指标。 130 | 131 | 132 | 133 | In this example an important decision was made – the focus was on increasing throughput, not on reducing latency. While increasing the throughput, we also needed to increase the capacity of the system. Instead of a single assembly line we now needed two assembly lines to produce the required quantity. So in this case the added throughput was not free, the solution needed to be scaled out in order to meet the increased throughput requirement. 134 | 135 | 136 | 137 | 这个例子中还做了一个重要的决定 —— 重点是增加吞吐量,而非减小延迟。在增加吞吐量的同时,我们也需要增加系统的能力。比起原来,我们现在需要两条流水线来生产所需的自行车数量。所以在这种情况下, 增加系统的吞吐量并不是免费的, 需要水平扩展, 以满足吞吐量增加的需求。 138 | 139 | 140 | 141 | An important alternative should also be considered for the performance problem at hand. The seemingly non-related latency of the system actually hides a different solution to the problem. If the latency of the assembly line could have been reduced from 1 minute to 30 seconds, the very same increase of throughput would suddenly be possible without any additional capacity. 142 | 143 | 144 | 145 | 在处理性能问题时, 也应该考虑到还有另外一种,看似不相关的解决办法。假如生产线的延迟从1分钟降低为30秒,那么吞吐量同样可以增加1倍。 146 | 147 | 148 | 149 | Whether or not reducing latency was possible or economical in this case is not relevant. What is important is a concept very similar to software engineering – you can almost always choose between two solutions to a performance problem. You can either throw more hardware towards the problem or spend time improving the poorly performing code. 150 | 151 | 152 | 不管是否能够降低延迟, 或者客户非常有钱。软件工程中有一种类似的说法 —— 每个性能问题,总有两种不同的解决办法。 可以使用更多的机器,也可以花功夫来改善性能低下的代码。 153 | 154 | 155 | 156 | ### Latency(延迟) 157 | 158 | 159 | 160 | 161 | Latency goals for the GC have to be derived from generic latency requirements. Generic latency requirements are typically expressed in a form similar to the following: 162 | 163 | 164 | GC的延迟指标是由一般的延迟需求决定的。延迟指标通常类似下面这些: 165 | 166 | 167 | 168 | - All user transactions must respond in less than 10 seconds 169 | - 90% of the invoice payments must be carried out in under 3 seconds 170 | - Recommended products must be rendered to a purchase screen in less than 100 ms 171 | 172 | 173 | 174 | - 用户的所有交易必须在10秒内得到响应 175 | - 90%的订单付款必须在3秒内处理完成 176 | - 推荐的产品必须在 100 ms 以内展示到购买界面 177 | 178 | 179 | 180 | 181 | When facing performance goals similar to the above, we would need to make sure that the duration of GC pauses during the transaction does not contribute too much to violating the requirements. “Too much” is application-specific and needs to take into account other factors contributing to latency including round-trips to external data sources, lock contention issues and other safe points among these. 182 | 183 | 184 | 在面临这一类性能指标时, 需要确保在交易中, GC暂停不能占用太多时间，否则就满足不了指标。“不能占用太多” 的意思根据各个系统的具体情况而定, 还要考虑到其他因素,包括外部数据源的往返时间(round-trips),锁竞争问题(lock contention),或者是其他的安全点。 185 | 186 | 187 | 188 | Let us assume our performance requirements state that 90% of the transactions to the application need to complete under 1,000 ms and no transaction can exceed 10,000 ms. Out of those generic latency requirements let us again assume that GC pauses cannot contribute more than 10%. From this, we can conclude that 90% of GC pauses have to complete under 100 ms, and no GC pause can exceed 1,000 ms. For simplicity’s sake let us ignore in this example multiple pauses that can occur during the same transaction. 189 | 190 | 191 | 假设性能需求为: `90%`的交易要在 `1000ms` 以内完成, 任何一次交易处理都不能超过`10秒`。 根据经验, 我们再次假设GC暂停时间不能超过10%。 也就是说, 90%的GC暂停需要在 `100ms` 内结束, 也不能有超过 `1000ms` 的GC暂停。为简单起见, 我们忽略在同一次交易中发生多次停顿的可能性。 192 | 193 | 194 | 195 | 196 | Having formalized the requirement, the next step is to measure pause durations. There are many tools for the job, covered in more detail in the chapter on Tooling, but in this section, let us use GC logs, namely for the duration of GC pauses. The information required is present in different log snippets so let us take a look which parts of date/time data are actually relevant, using the following example: 197 | 198 | 199 | 200 | 有了正式的需求,下一步就是衡量暂停时间。有许多工具可以帮助我们, 在接下来的 [GC 调优(工具篇)](06_GC_Tuning_Tooling.md) 中会进行详细介绍, 但我们在本节中可以查看GC日志, 检查一下GC暂停的时间。相关的信息分布在不同的日志片段中, 一起来看如下示例中的数据: 201 | 202 | 203 | 204 | 205 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 206 | [PSYoungGen: 93677K->70109K(254976K)] 207 | [ParOldGen: 499597K->511230K(761856K)] 208 | 593275K->581339K(1016832K), 209 | [Metaspace: 2936K->2936K(1056768K)] 210 | , 0.0713174 secs] 211 | [Times: user=0.21 sys=0.02, real=0.07 secs 212 | 213 | 214 | 215 | The example above expresses a single GC pause triggered at 13:34:16 on June 4, 2015, just 2,578 ms after the JVM was started. 216 | 217 | 218 | 示例表示的是单次GC暂停, 在 `2015-06-04T13:34:16` 这个时刻触发. 对应于JVM启动之后的 `2,578 ms`。 219 | 220 | 221 | 222 | The event stopped the application threads for 0.0713174 seconds. Even though it took 210 ms of CPU times on multiple cores, the important number for us to measure is the total stop time for application threads, which in this case, where parallel GC was used on a multi-core machine, is equal to a bit more than 70 ms. This specific GC pause is thus well under the required 100 ms threshold and fulfils both requirements. 223 | 224 | 225 | 此事件让应用线程暂停了 `0.0713174` 秒。虽然花费的总时间为 210 ms, 但因为是在多核CPU的机器上, 所以最重要的数字是应用线程被暂停的总时间, 在这里使用并行GC, 所以大约是 `70ms` 左右。因此这次GC的暂停时间低于 `100ms` 的阈值，所以满足需求。 226 | 227 | 228 | Extracting information similar to the example above from all GC pauses, we can aggregate the numbers and see whether or not we are violating the set requirements for any of the pause events triggered. 229 | 230 | 231 | 如同上面这样, 从所有GC日志中提取出暂停相关的数值信息, 汇总之后就可以得知是否满足需求。 232 | 233 | 234 | 235 | 236 | ### Throughput(吞吐量) 237 | 238 | 239 | 240 | 241 | Throughput requirements are different from latency requirements. The only similarity that the throughput requirements share with latency is the fact that again, these requirements need to be derived from generic throughput requirements. Generic requirements for throughput can be similar to the following: 242 | 243 | 244 | 245 | 吞吐量和延迟有很大区别。唯一相似的是两者都是根据一般吞吐量需求而得来的。一般吞吐量需求(Generic requirements for throughput) 类似下面这样: 246 | 247 | 248 | 249 | - The solution must be able to process 1,000,000 invoices/day 250 | - The solution must support 1,000 authenticated users each invoking one of the functions A, B or C every five to ten seconds 251 | - Weekly statistics for all customers have to be composed in no more than six hours each Sunday night between 12 PM and 6 AM 252 | 253 | 254 | - 解决方案每天必须能处理 100万个订单 255 | - 解决方案必须支持1000个登录用户同时在5-10秒内执行一个功能: A、B或C 256 | - 每周对所有客户的统计时间不能超过6个小时，时间窗口为每周日晚12点到次日6点之间。 257 | 258 | 259 | 260 | 261 | So, instead of setting requirements for a single operation, the requirements for throughput specify how many operations the system must process in a given time unit. Similar to the latency requirements, the GC tuning part now requires determining the total time that can be spent on GC during the time measured. How much is tolerable for the particular system is again application-specific, but as a rule of thumb, anything over 10% would look suspicious. 262 | 263 | 264 | 可以看出,吞吐量需求不是针对单个操作的, 而是在给定的时间范围内, 系统必须处理完成多少个操作。和延迟需求类似, GC调优也需要确定在GC期间消耗的总时间。每个系统能接受的时间都不一样, 但一般来说, GC占用的总时间比例不能超过 10%。 265 | 266 | 267 | 268 | Let us now assume that the requirement at hand foresees that the system processes 1,000 transactions per minute. Let us also assume that the total duration of GC pauses during any minute cannot exceed six seconds (or 10%) of this time. 269 | 270 | 271 | 现在假设需求是: 每分钟要处理 1000 个交易。同时假设, 每分钟GC暂停的总时间不能超过6秒(即10%)。 272 | 273 | 274 | 275 | Having formalized the requirements, the next step would be to harvest the information we need. The source to be used in the example is again GC logs, from which we would get information similar to the following: 276 | 277 | 278 | 有了正式的需求, 下一步就是获取相关的信息。数据依然是从GC日志中提取, 可以看到类似下面这样的信息: 279 | 280 | 281 | 282 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 283 | [PSYoungGen: 93677K->70109K(254976K)] 284 | [ParOldGen: 499597K->511230K(761856K)] 285 | 593275K->581339K(1016832K), 286 | [Metaspace: 2936K->2936K(1056768K)], 287 | 0.0713174 secs] 288 | [Times: user=0.21 sys=0.02, real=0.07 secs 289 | 290 | 291 | 292 | 293 | This time we are interested in user and system times instead of real time. In this case we should focus on 23 milliseconds (21 + 2 ms in user and system times) during which the particular GC pause kept CPUs busy. Even more important is the fact that the system was running on a multi-core machine, translating to the actual stop-the-world pause of 0.0713174 seconds, which is the number to be used in the following calculations. 294 | 295 | 296 | 现在我们对 用户耗时(user)和系统耗时(sys)感兴趣,而不再关心实际耗时(real)。在这里, 我们关心的时间为 `0.23s`(user + sys = 0.21 + 0.02 s), 这段时间内, GC暂停zhany消耗了 cpu 资源。 重要的是, 系统运行在多核机器上, 转换为实际的停顿时间(stop-the-world)为 `0.0713174秒`, 下面的计算会用到这个数字。 297 | 298 | 299 | Extracting the information similar to the above from the GC logs across the test period, all that is left to be done is to verify the total duration of the stop-the-world pauses during each minute. In case the total duration of the pauses does not exceed 6,000ms or six seconds in any of these one-minute periods, we have fulfilled our requirement. 300 | 301 | 302 | 从GC日志中提取出相应的信息后, 剩下要做的就是统计每分钟内GC停顿的总时间。看看是否满足我们的要求: 每分钟内,总的暂停时间不得超过6000毫秒(6秒)。 303 | 304 | 305 | 306 | 307 | ### Capacity(系统容量) 308 | 309 | 310 | 311 | Capacity requirements put additional constraints on the environment where the throughput and latency goals can be met. These requirements might be expressed either in terms of computing resources or in cold hard cash. The ways in which such requirements can be described can, for example, take the following form: 312 | 313 | 系统容量(Capacity)需求是在对达成吞吐量和延迟指标的情况下对环境的额外约束。这类需求大多是来源于计算资源或者预算方面的原因。例如: 314 | 315 | 316 | 317 | - The system must be deployed on Android devices with less than 512 MB of memory 318 | - The system must be deployed on Amazon EC2 The maximum required instance size must not exceed the configuration c3.xlarge (8 G, 4 cores) 319 | - The monthly invoice from Amazon EC2 for running the system must not exceed $12,000 320 | 321 | 322 | 323 | - 系统必须能部署到小于512 MB内存的Android设备上 324 | - 系统必须部署在Amazon **EC2**实例上, 不得超过 **c3.xlarge(4核8G)**的配置。 325 | - 每个月 Amazon EC2的账单不得超过 $12,000 326 | 327 | 328 | 329 | Thus, capacity has to be taken into account when fulfilling the latency and throughput requirements. With unlimited computing power, any kind of latency and throughput targets could be met, yet in the real world the budget and other constraints have a tendency to set limits on the resources one can use. 330 | 331 | 332 | 因此, 在满足延迟和吞吐量需求的基础上必须考虑系统容量。如果有无限的计算资源可供挥霍, 那么任何 延迟和吞吐量指标 都不是问题, 但现实情况是, 预算(budget)和其他约束限制了可用的资源。 333 | 334 | 335 | ## 相关示例 336 | 337 | 338 | 339 | 340 | Now that we have covered the three dimensions of performance tuning, we can start investigating setting and hitting GC performance goals in practice. 341 | 342 | 343 | 介绍完性能调优的三个维度之后, 我们进行实际的配置以达成GC性能指标。 344 | 345 | 346 | For this purpose, let us take a look at an example code: 347 | 348 | 349 | 请看下面的示例代码: 350 | 351 | 352 | 353 | //imports skipped for brevity 354 | public class Producer implements Runnable { 355 | 356 | private static ScheduledExecutorService executorService 357 | = Executors.newScheduledThreadPool(2); 358 | 359 | private Deque deque; 360 | private int objectSize; 361 | private int queueSize; 362 | 363 | public Producer(int objectSize, int ttl) { 364 | this.deque = new ArrayDeque(); 365 | this.objectSize = objectSize; 366 | this.queueSize = ttl * 1000; 367 | } 368 | 369 | @Override 370 | public void run() { 371 | for (int i = 0; i < 100; i++) { 372 | deque.add(new byte[objectSize]); 373 | if (deque.size() > queueSize) { 374 | deque.poll(); 375 | } 376 | } 377 | } 378 | 379 | public static void main(String[] args) 380 | throws InterruptedException { 381 | executorService.scheduleAtFixedRate( 382 | new Producer(200 * 1024 * 1024 / 1000, 5), 383 | 0, 100, TimeUnit.MILLISECONDS 384 | ); 385 | executorService.scheduleAtFixedRate( 386 | new Producer(50 * 1024 * 1024 / 1000, 120), 387 | 0, 100, TimeUnit.MILLISECONDS); 388 | TimeUnit.MINUTES.sleep(10); 389 | executorService.shutdownNow(); 390 | } 391 | } 392 | 393 | 394 | 395 | 396 | 397 | The code submits two jobs to run every 100 ms. Each job emulates objects with a specific lifespan: it creates objects, lets them leave for a predetermined amount of time and then forgets about them, allowing GC to reclaim the memory. 398 | 399 | 400 | 这段程序代码每 100毫秒 提交两个作业(job)来执行。每个作业都模拟特定的生命周期: 先创建对象,然后在预定的时间释放, 接着就不管了, 之后GC就可以回收对应的内存。 401 | 402 | 403 | 404 | When running the example with GC logging turned on with the following parameters: 405 | 406 | 407 | 在运行这个示例程序时，通过以下参数打开GC日志记录: 408 | 409 | 410 | -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 411 | 412 | 413 | 还应该加上JVM参数 `-Xloggc`以指定GC日志的存储位置,类似这样: 414 | 415 | -Xloggc:C:\\Producer_gc.log 416 | 417 | 418 | we immediately see the impact of GC in the log files, similarly to the following: 419 | 420 | 421 | 在日志文件中我们可以看到GC的行为, 类似下面这样: 422 | 423 | 424 | 425 | 426 | 2015-06-04T13:34:16.119-0200: 1.723: [GC (Allocation Failure) 427 | [PSYoungGen: 114016K->73191K(234496K)] 428 | 421540K->421269K(745984K), 429 | 0.0858176 secs] 430 | [Times: user=0.04 sys=0.06, real=0.09 secs] 431 | 432 | 2015-06-04T13:34:16.738-0200: 2.342: [GC (Allocation Failure) 433 | [PSYoungGen: 234462K->93677K(254976K)] 434 | 582540K->593275K(766464K), 435 | 0.2357086 secs] 436 | [Times: user=0.11 sys=0.14, real=0.24 secs] 437 | 438 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 439 | [PSYoungGen: 93677K->70109K(254976K)] 440 | [ParOldGen: 499597K->511230K(761856K)] 441 | 593275K->581339K(1016832K), 442 | [Metaspace: 2936K->2936K(1056768K)], 443 | 0.0713174 secs] 444 | [Times: user=0.21 sys=0.02, real=0.07 secs] 445 | 446 | 447 | 448 | 449 | 450 | Based on the information in the log we can start improving the situation with three different goals in mind: 451 | 452 | 453 | 基于日志中的信息, 可以通过三个优化目标来提升性能: 454 | 455 | 456 | 457 | 1. Making sure the worst-case GC pause does not exceed a predetermined threshold 458 | 2. Making sure the total time during which application threads are stopped does not exceed a predetermined threshold 459 | 3. Reducing infrastructure costs while making sure we can still achieve reasonable latency and/or throughput targets 460 | 461 |
462 | 463 | 1. 确保最坏情况下,GC暂停时间不超过预定的阀值 464 | 2. 确保线程暂停的总时间, 不超过预定的阀值 465 | 3. 在确保可以达到延迟和吞吐量指标的情况下, 降低硬件的配置和成本。 466 | 467 | 468 | 469 | 470 | For this, the code above was run for 10 minutes on three different configurations providing three very different results summarized in the following table: 471 | 472 | 473 | 为此, 用三种不同的配置, 将以上代码运行10分钟, 得到了三种不同的结果, 汇总之后如下所示: 474 | 475 | 476 | 477 | 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 | 489 | 490 | 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
507 | 508 | 509 | 510 | 511 | The experiment ran the same code with different GC algorithms and different heap sizes to measure the duration of Garbage Collection pauses with regards to latency and throughput. Details of the experiments and an interpretation of the results are given in the following chapters. 512 | 513 | 514 | 515 | 通过不同的GC算法,以及不同的堆内存配置,运行相同的代码, 以测量GC暂停时间与延迟、吞吐量之间的关系。实验的细节和结果将在后面的章节介绍。 516 | 517 | 518 | 519 | 520 | Note that in order to keep the example as simple as possible only a limited amount of input parameters were changed, for example the experiments do not test on different number of cores or with a different heap layout. 521 | 522 | 523 | 注意, 为了尽可能的简单, 示例中只改变了很少的输入参数, 此实验也没有在不同的CPU数量以及不同的堆布局下进行测试。 524 | 525 | 526 | ### Tuning for Latency(优化延迟指标) 527 | 528 | 529 | 530 | Let us assume we have a requirement stating that all jobs must be processed in under 1,000 ms. Knowing that the actual job processing takes just 100 ms we can simplify and deduct the latency requirement for individual GC pauses. Our requirement now states that no GC pause can stop the application threads for longer than 900 ms. Answering this question is easy, one would just need to parse the GC log files and find the maximum pause time for an individual GC pause. 531 | 532 | 533 | 534 | 假设有一个需求, **每次作业必须在 1000ms 内处理完成**。我们知道, 实际的作业处理只需要100 ms，简化后可以算出， 两者相减就是对 GC暂停的延迟要求。现在需求变成这种形式: **GC暂停不能超过900ms**。这个问题很容易找到答案, 只需要解析GC日志文件, 并找出每次GC暂停中最大的那个暂停时间即可。 535 | 536 | 537 | 538 | Looking again at the three configuration options used in the test: 539 | 540 | 541 | 再来看上面测试所用的三份配置: 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | 561 | 562 | 563 | 564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
574 | 575 | 576 | we can see that there is one configuration that already matches this requirement. Running the code with: 577 | 578 | 579 | 我们可以看到,其中有一个配置已经达到了此项要求。运行的参数为: 580 | 581 | 582 | java -Xmx12g -XX:+UseConcMarkSweepGC Producer 583 | 584 | 585 | results in a maximum GC pause of 560 ms, which nicely passes the 900 ms threshold set for satisfying the latency requirement. If neither the throughput nor the capacity requirements are violated, we can conclude that we have fulfilled our GC tuning task and can finish the tuning exercise. 586 | 587 | 588 | 对应日志中最长的GC停顿时间为 `560 ms`, 这达到了设置的延迟指标 `900 ms` 的要求。如果还满足吞吐量和系统容量的要求,就可以得出结论, 我们已经成功达成了GC调优目标, 可以结束调优活动了。 589 | 590 | 591 | 592 | 593 | ### Tuning for Throughput(吞吐量调优) 594 | 595 | 596 | 597 | 598 | Let us assume that we have a throughput goal to process 13,000,000 jobs/hour. The example configurations used again give us a configuration where the requirement is fulfilled: 599 | 600 | 601 | 假定我们的吞吐量指标是: **每小时处理 1300万次操作**。再次使用上面的配置, 其中有一个配置满足我们的需求: 602 | 603 | 604 | 605 | 606 | 607 | 608 | 609 | 610 | 611 | 612 | 613 | 614 | 615 | 616 | 617 | 618 | 619 | 620 | 621 | 622 | 623 | 624 | 625 | 626 | 627 | 628 | 629 | 630 | 631 | 632 | 633 | 634 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
635 | 636 | 637 | 638 | 639 | 640 | Running this configuration as: 641 | 642 | 643 | 执行此配置的命令行参数为: 644 | 645 | 646 | java -Xmx12g -XX:+UseParallelGC Producer 647 | 648 | 649 | we can see that the CPUs are blocked by GC for 8.5% of the time, leaving 91.5% of the computing power for useful work. For simplicity’s sake we will ignore other safe points in the example. Now we have to take into account that: 650 | 651 | 652 | 可以看到,GC占用了 8.5%的CPU时间,剩下的 `91.5%` 是有效的计算时间。为简单起见, 忽略示例中的其他安全点。现在需要考虑: 653 | 654 | 655 | 656 | 1. One job is processed in 100 ms by a single core 657 | 2. Thus, in one minute, 60,000 jobs could be processed by one core 658 | 3. In one hour, a single core could thus process 3.6 M jobs 659 | 4. We have four cores available, which could thus process 4 x 3.6 M = 14.4 M jobs in an hour 660 | 661 |
662 | 663 | 664 | 1. 每个CPU核心处理一次作业需要耗时 `100ms` 665 | 2. 因此, 一分钟内每个核心可以处理 60,000 次操作(**每个job完成100次操作**) 666 | 3. 在一个小时内,一个核心可以处理 360万次操作 667 | 4. 我们有四个可用的内核, 则每小时可以处理 4 x 3.6M = 1440万次操作 668 | 669 | 670 | 671 | 672 | With this amount of theoretical processing power we can make a simple calculation and conclude that during one hour we can in reality process 91.5% of the 14.4 M theoretical maximum resulting in 13,176,000 processed jobs/hour, fulfilling our requirement. 673 | 674 | 675 | 理论上，通过简单的计算就可以得出结论, 每小时可以处理的实际操作数为: `14.4 M * 91.5% = 13,176,000` 次操作, 满足了需求。 676 | 677 | 678 | It is important to note that if we simultaneously needed to fulfill the latency requirements set in the previous section, we would be in trouble, as the worst-case latency for this case is close to two times of the previous configuration. This time the longest GC pause on record was blocking the application threads for 1,104 ms. 679 | 680 | 681 | 值得一提的是, 假若还要满足上一节中的延迟性需求, 那就有大麻烦了, 最坏情况下的延迟时间是上一种配置的两倍左右。此次最长的GC暂停时间为 `1,104 ms`。 682 | 683 | 684 | 685 | 686 | ### Tuning for Capacity(对系统容量进行调优) 687 | 688 | 689 | 690 | 691 | Let us assume we have to deploy our solution to the commodity-class hardware with up to four cores and 10 G RAM available. From this we can derive our capacity requirement that the maximum heap space for the application cannot exceed 8 GB. Having this requirement in place, we would need to turn to the third configuration on which the test was run: 692 | 693 | 694 | 假设需要将软件部署到服务器上(commodity-class hardware), 配置为 `4核10G`。这样的话, 系统容量的要求就变成: 最大的堆内存空间不能超过 `8GB`。有了这个需求, 我们需要调整到第三套配置来进行测试: 695 | 696 | 697 | 698 | 699 | 700 | 701 | 702 | 703 | 704 | 705 | 706 | 707 | 708 | 709 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | 721 | 722 | 723 | 724 | 725 | 726 | 727 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
728 | 729 | 730 | 731 | 732 | 733 | The application is able to run on this configuration as 734 | 735 | 736 | 程序可以通过如下参数执行: 737 | 738 | 739 | java -Xmx8g -XX:+UseConcMarkSweepGC Producer 740 | 741 | 742 | but both the latency and especially throughput numbers fall drastically: 743 | 744 | 745 | 746 | 但结果是延迟大幅增长, 而且吞吐量也大幅下降: 747 | 748 | 749 | 750 | 751 | - GC now blocks CPUs from doing useful work a lot more, as this configuration only leaves 66.3% of the CPUs for useful work. As a result, this configuration would drop the throughput from the best-case-scenario of 13,176,000 jobs/hour to a meager 9,547,200 jobs/hour 752 | - Instead of 560 ms we are now facing 1,610 ms of added latency in the worst case 753 | 754 |
755 | 756 | 757 | - 现在,GC占用了更多的CPU资源, 这种配置只有 `66.3%` 的有效CPU时间。因此,这个配置让吞吐量从最好的情况 **13,176,000 操作/小时** 下降到 **不足 9,547,200次操作/小时**. 758 | - 最坏情况延迟的不再是 **560ms**，而是变成 **1,610 ms** 759 | 760 | 761 | 762 | 763 | 764 | Walking through the three dimensions it is indeed obvious that you cannot just optimize for “performance” but instead need to think in three different dimensions, measuring and tuning both latency and throughput, and taking the capacity constraints into account. 765 | 766 | 767 | 768 | 通过这三个维度的讲解, 我们了解到, 不只是简单的进行“性能(performance)”优化, 而是需要从三个不同的维度来进行考虑, 测量并调优 延迟和吞吐量, 还要考虑系统容量约束。 769 | 770 | 771 | 772 | 773 | 原文链接: [GC Tuning: Basics](https://plumbr.eu/handbook/gc-tuning) 774 | 775 | 776 | 777 | 778 | 779 |
780 | 781 | 782 | -------------------------------------------------------------------------------- /05_GC_Tuning_Basics_CN.md: -------------------------------------------------------------------------------- 1 | # 5. GC 调优(基础篇) 2 | 3 | 4 | > **说明**: 5 | > 6 | > **Capacity**: 性能,能力,系统容量; 文中翻译为"**系统容量**"; 意为硬件配置。 7 | 8 | 9 | GC调优(Tuning Garbage Collection)和其他性能调优是同样的原理。初学者可能会被 200 多个 GC参数弄得一头雾水, 然后随便调整几个来试试结果,又或者修改几行代码来测试。其实只要参照下面的步骤，就能保证你的调优方向正确: 10 | 11 | 12 | 1. 列出性能调优指标(State your performance goals) 13 | 2. 执行测试(Run tests) 14 | 3. 检查结果(Measure the results) 15 | 4. 与目标进行对比(Compare the results with the goals) 16 | 5. 如果达不到指标, 修改配置参数, 然后继续测试(go back to running tests) 17 | 18 | 19 | 第一步, 我们需要做的事情就是: 制定明确的GC性能指标。对所有性能监控和管理来说, 有三个维度是通用的: 20 | 21 | 22 | - Latency(延迟) 23 | - Throughput(吞吐量) 24 | - Capacity(系统容量) 25 | 26 | 27 | 我们先讲解基本概念,然后再演示如何使用这些指标。如果您对 延迟、吞吐量和系统容量等概念很熟悉, 可以跳过这一小节。 28 | 29 | 30 | ## 核心概念(Core Concepts) 31 | 32 | 33 | 我们先来看一家工厂的装配流水线。工人在流水线将现成的组件按顺序拼接,组装成自行车。通过实地观测, 我们发现从组件进入生产线，到另一端组装成自行车需要4小时。 34 | 35 | 36 | ![](05_01_assembly-line01-compact.jpg) 37 | 38 | 39 | 继续观察,我们还发现,此后每分钟就有1辆自行车完成组装, 每天24小时,一直如此。将这个模型简化, 并忽略维护窗口期后得出结论： **这条流水线每小时可以组装60辆自行车**。 40 | 41 | > **说明**: 时间窗口/窗口期，请类比车站卖票的窗口，是一段规定/限定做某件事的时间段。 42 | 43 | 44 | 通过这两种测量方法, 就知道了生产线的相关性能信息： **延迟**与**吞吐量**: 45 | 46 | - 生产线的延迟: **4小时** 47 | - 生产线的吞吐量: **60辆/小时** 48 | 49 | 50 | 请注意, 衡量延迟的时间单位根据具体需要而确定 —— 从纳秒(nanosecond)到几千年(millennia)都有可能。系统的吞吐量是每个单位时间内完成的操作。操作(Operations)一般是特定系统相关的东西。在本例中,选择的时间单位是小时, 操作就是对自行车的组装。 51 | 52 | 53 | 掌握了延迟和吞吐量两个概念之后, 让我们对这个工厂来进行实际的调优。自行车的需求在一段时间内都很稳定, 生产线组装自行车有四个小时延迟, 而吞吐量在几个月以来都很稳定: 60辆/小时。假设某个销售团队突然业绩暴涨, 对自行车的需求增加了1倍。客户每天需要的自行车不再是 60 * 24 = 1440辆, 而是 2*1440 = 2880辆/天。老板对工厂的产能不满意，想要做些调整以提升产能。 54 | 55 | 56 | 看起来总经理很容易得出正确的判断, 系统的延迟没法子进行处理 —— 他关注的是每天的自行车生产总量。得出这个结论以后, 假若工厂资金充足, 那么应该立即采取措施, 改善吞吐量以增加产能。 57 | 58 | 59 | 我们很快会看到, 这家工厂有两条相同的生产线。每条生产线一分钟可以组装一辆成品自行车。 可以想象，每天生产的自行车数量会增加一倍。达到 2880辆/天。要注意的是, 不需要减少自行车的装配时间 —— 从开始到结束依然需要 4 小时。 60 | 61 | 62 | ![](05_02_assembly-line02-compact.jpg) 63 | 64 | 65 | 巧合的是，这样进行的性能优化,同时增加了吞吐量和产能。一般来说，我们会先测量当前的系统性能, 再设定新目标, 只优化系统的某个方面来满足性能指标。 66 | 67 | 68 | 在这里做了一个很重要的决定 —— 要增加吞吐量,而不是减小延迟。在增加吞吐量的同时, 也需要增加系统容量。比起原来的情况, 现在需要两条流水线来生产出所需的自行车。在这种情况下, 增加系统的吞吐量并不是免费的, 需要水平扩展, 以满足增加的吞吐量需求。 69 | 70 | 71 | 在处理性能问题时, 应该考虑到还有另一种看似不相关的解决办法。假如生产线的延迟从1分钟降低为30秒,那么吞吐量同样可以增长 1 倍。 72 | 73 | 74 | 或者是降低延迟, 或者是客户非常有钱。软件工程里有一种相似的说法 —— 每个性能问题背后,总有两种不同的解决办法。 可以用更多的机器, 或者是花精力来改善性能低下的代码。 75 | 76 | 77 | ### Latency(延迟) 78 | 79 | 80 | GC的延迟指标由一般的延迟需求决定。延迟指标通常如下所述: 81 | 82 | 83 | - 所有交易必须在10秒内得到响应 84 | - 90%的订单付款操作必须在3秒以内处理完成 85 | - 推荐商品必须在 100 ms 内展示到用户面前 86 | 87 | 88 | 面对这类性能指标时, 需要确保在交易过程中, GC暂停不能占用太多时间，否则就满足不了指标。“不能占用太多” 的意思需要视具体情况而定, 还要考虑到其他因素, 比如外部数据源的交互时间(round-trips), 锁竞争(lock contention), 以及其他的安全点等等。 89 | 90 | 91 | 假设性能需求为: `90%`的交易要在 `1000ms` 以内完成, 每次交易最长不能超过 `10秒`。 根据经验, 假设GC暂停时间比例不能超过10%。 也就是说, 90%的GC暂停必须在 `100ms` 内结束, 也不能有超过 `1000ms` 的GC暂停。为简单起见, 我们忽略在同一次交易过程中发生多次GC停顿的可能性。 92 | 93 | 94 | 有了正式的需求,下一步就是检查暂停时间。有许多工具可以使用, 在接下来的 [6. GC 调优(工具篇)](06_GC_Tuning_Tooling.md) 中会进行详细的介绍, 在本节中我们通过查看GC日志, 检查一下GC暂停的时间。相关的信息散落在不同的日志片段中, 看下面的数据: 95 | 96 | 97 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 98 | [PSYoungGen: 93677K->70109K(254976K)] 99 | [ParOldGen: 499597K->511230K(761856K)] 100 | 593275K->581339K(1016832K), 101 | [Metaspace: 2936K->2936K(1056768K)] 102 | , 0.0713174 secs] 103 | [Times: user=0.21 sys=0.02, real=0.07 secs 104 | 105 | 106 | 这表示一次GC暂停, 在 `2015-06-04T13:34:16` 这个时刻触发. 对应于JVM启动之后的 `2,578 ms`。 107 | 108 | 109 | 此事件将应用线程暂停了 `0.0713174` 秒。虽然花费的总时间为 210 ms, 但因为是多核CPU机器, 所以最重要的数字是应用线程被暂停的总时间, 这里使用的是并行GC, 所以暂停时间大约为 `70ms` 。 这次GC的暂停时间小于 `100ms` 的阈值，满足需求。 110 | 111 | 112 | 继续分析, 从所有GC日志中提取出暂停相关的数据, 汇总之后就可以得知是否满足需求。 113 | 114 | 115 | ### Throughput(吞吐量) 116 | 117 | 118 | 吞吐量和延迟指标有很大区别。当然两者都是根据一般吞吐量需求而得出的。一般吞吐量需求(Generic requirements for throughput) 类似这样: 119 | 120 | 121 | - 解决方案每天必须处理 100万个订单 122 | - 解决方案必须支持1000个登录用户,同时在5-10秒内执行某个操作: A、B或C 123 | - 每周对所有客户进行统计, 时间不能超过6小时，时间窗口为每周日晚12点到次日6点之间。 124 | 125 | 126 | 可以看出,吞吐量需求不是针对单个操作的, 而是在给定的时间内, 系统必须完成多少个操作。和延迟需求类似, GC调优也需要确定GC行为所消耗的总时间。每个系统能接受的时间不同, 一般来说, GC占用的总时间比不能超过 `10%`。 127 | 128 | 129 | 现在假设需求为: 每分钟处理 1000 笔交易。同时, 每分钟GC暂停的总时间不能超过6秒(即10%)。 130 | 131 | 132 | 有了正式的需求, 下一步就是获取相关的信息。依然是从GC日志中提取数据, 可以看到类似这样的信息: 133 | 134 | 135 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 136 | [PSYoungGen: 93677K->70109K(254976K)] 137 | [ParOldGen: 499597K->511230K(761856K)] 138 | 593275K->581339K(1016832K), 139 | [Metaspace: 2936K->2936K(1056768K)], 140 | 0.0713174 secs] 141 | [Times: user=0.21 sys=0.02, real=0.07 secs 142 | 143 | 144 | 此时我们对 用户耗时(user)和系统耗时(sys)感兴趣, 而不关心实际耗时(real)。在这里, 我们关心的时间为 `0.23s`(user + sys = 0.21 + 0.02 s), 这段时间内, GC暂停占用了 cpu 资源。 重要的是, 系统运行在多核机器上, 转换为实际的停顿时间(stop-the-world)为 `0.0713174秒`, 下面的计算会用到这个数字。 145 | 146 | 147 | 提取出有用的信息后, 剩下要做的就是统计每分钟内GC暂停的总时间。看看是否满足需求: 每分钟内总的暂停时间不得超过6000毫秒(6秒)。 148 | 149 | 150 | ### Capacity(系统容量) 151 | 152 | 153 | 系统容量(Capacity)需求,是在达成吞吐量和延迟指标的情况下,对硬件环境的额外约束。这类需求大多是来源于计算资源或者预算方面的原因。例如: 154 | 155 | 156 | - 系统必须能部署到小于512 MB内存的Android设备上 157 | - 系统必须部署在Amazon **EC2**实例上, 配置不得超过 **c3.xlarge(4核8GB)**。 158 | - 每月的 Amazon EC2 账单不得超过 `$12,000` 159 | 160 | 161 | 因此, 在满足延迟和吞吐量需求的基础上必须考虑系统容量。可以说, 假若有无限的计算资源可供挥霍, 那么任何 延迟和吞吐量指标 都不成问题, 但现实情况是, 预算(budget)和其他约束限制了可用的资源。 162 | 163 | 164 | ## 相关示例 165 | 166 | 167 | 介绍完性能调优的三个维度后, 我们来进行实际的操作以达成GC性能指标。 168 | 169 | 170 | 请看下面的代码: 171 | 172 | 173 | //imports skipped for brevity 174 | public class Producer implements Runnable { 175 | 176 | private static ScheduledExecutorService executorService 177 | = Executors.newScheduledThreadPool(2); 178 | 179 | private Deque deque; 180 | private int objectSize; 181 | private int queueSize; 182 | 183 | public Producer(int objectSize, int ttl) { 184 | this.deque = new ArrayDeque(); 185 | this.objectSize = objectSize; 186 | this.queueSize = ttl * 1000; 187 | } 188 | 189 | @Override 190 | public void run() { 191 | for (int i = 0; i < 100; i++) { 192 | deque.add(new byte[objectSize]); 193 | if (deque.size() > queueSize) { 194 | deque.poll(); 195 | } 196 | } 197 | } 198 | 199 | public static void main(String[] args) 200 | throws InterruptedException { 201 | executorService.scheduleAtFixedRate( 202 | new Producer(200 * 1024 * 1024 / 1000, 5), 203 | 0, 100, TimeUnit.MILLISECONDS 204 | ); 205 | executorService.scheduleAtFixedRate( 206 | new Producer(50 * 1024 * 1024 / 1000, 120), 207 | 0, 100, TimeUnit.MILLISECONDS); 208 | TimeUnit.MINUTES.sleep(10); 209 | executorService.shutdownNow(); 210 | } 211 | } 212 | 213 | 214 | 215 | 这段程序代码, 每 100毫秒 提交两个作业(job)来。每个作业都模拟特定的生命周期: 创建对象, 然后在预定的时间释放, 接着就不管了, 由GC来自动回收占用的内存。 216 | 217 | 218 | 在运行这个示例程序时，通过以下JVM参数打开GC日志记录: 219 | 220 | 221 | -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps 222 | 223 | 224 | 还应该加上JVM参数 `-Xloggc`以指定GC日志的存储位置,类似这样: 225 | 226 | -Xloggc:C:\\Producer_gc.log 227 | 228 | 229 | 在日志文件中可以看到GC的行为, 类似下面这样: 230 | 231 | 232 | 2015-06-04T13:34:16.119-0200: 1.723: [GC (Allocation Failure) 233 | [PSYoungGen: 114016K->73191K(234496K)] 234 | 421540K->421269K(745984K), 235 | 0.0858176 secs] 236 | [Times: user=0.04 sys=0.06, real=0.09 secs] 237 | 238 | 2015-06-04T13:34:16.738-0200: 2.342: [GC (Allocation Failure) 239 | [PSYoungGen: 234462K->93677K(254976K)] 240 | 582540K->593275K(766464K), 241 | 0.2357086 secs] 242 | [Times: user=0.11 sys=0.14, real=0.24 secs] 243 | 244 | 2015-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 245 | [PSYoungGen: 93677K->70109K(254976K)] 246 | [ParOldGen: 499597K->511230K(761856K)] 247 | 593275K->581339K(1016832K), 248 | [Metaspace: 2936K->2936K(1056768K)], 249 | 0.0713174 secs] 250 | [Times: user=0.21 sys=0.02, real=0.07 secs] 251 | 252 | 253 | 基于日志中的信息, 可以通过三个优化目标来提升性能: 254 | 255 | 256 | 1. 确保最坏情况下,GC暂停时间不超过预定阀值 257 | 2. 确保线程暂停的总时间不超过预定阀值 258 | 3. 在确保达到延迟和吞吐量指标的情况下, 降低硬件配置以及成本。 259 | 260 | 261 | 为此, 用三种不同的配置, 将代码运行10分钟, 得到了三种不同的结果, 汇总如下: 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
295 | 296 | 297 | 298 | 使用不同的GC算法,和不同的内存配置,运行相同的代码, 以测量GC暂停时间与 延迟、吞吐量的关系。实验的细节和结果在后面章节详细介绍。 299 | 300 | 301 | 注意, 为了尽量简单, 示例中只改变了很少的输入参数, 此实验也没有在不同CPU数量或者不同的堆布局下进行测试。 302 | 303 | 304 | ### Tuning for Latency(调优延迟指标) 305 | 306 | 307 | 假设有一个需求, **每次作业必须在 1000ms 内处理完成**。我们知道, 实际的作业处理只需要100 ms，简化后， 两者相减就可以算出对 GC暂停的延迟要求。现在需求变成: **GC暂停不能超过900ms**。这个问题很容易找到答案, 只需要解析GC日志文件, 并找出GC暂停中最大的那个暂停时间即可。 308 | 309 | 310 | 再来看测试所用的三个配置: 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
344 | 345 | 346 | 347 | 可以看到,其中有一个配置达到了要求。运行的参数为: 348 | 349 | 350 | java -Xmx12g -XX:+UseConcMarkSweepGC Producer 351 | 352 | 353 | 对应的GC日志中,暂停时间最大为 `560 ms`, 这达到了延迟指标 `900 ms` 的要求。如果还满足吞吐量和系统容量需求的话,就可以说成功达成了GC调优目标, 调优结束。 354 | 355 | 356 | ### Tuning for Throughput(吞吐量调优) 357 | 358 | 359 | 假定吞吐量指标为: **每小时完成 1300万次操作处理**。同样是上面的配置, 其中有一种配置满足了需求: 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | 392 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
393 | 394 | 395 | 396 | 此配置对应的命令行参数为: 397 | 398 | 399 | java -Xmx12g -XX:+UseParallelGC Producer 400 | 401 | 402 | 可以看到,GC占用了 8.5%的CPU时间,剩下的 `91.5%` 是有效的计算时间。为简单起见, 忽略示例中的其他安全点。现在需要考虑: 403 | 404 | 405 | 1. 每个CPU核心处理一次作业需要耗时 `100ms` 406 | 2. 因此, 一分钟内每个核心可以执行 60,000 次操作(**每个job完成100次操作**) 407 | 3. 一小时内, 一个核心可以执行 360万次操作 408 | 4. 有四个CPU内核, 则每小时可以执行: 4 x 3.6M = 1440万次操作 409 | 410 | 411 | 理论上，通过简单的计算就可以得出结论, 每小时可以执行的操作数为: `14.4 M * 91.5% = 13,176,000` 次, 满足需求。 412 | 413 | 414 | 值得一提的是, 假若还要满足延迟指标, 那就有问题了, 最坏情况下, GC暂停时间为 `1,104 ms`, 最大延迟时间是前一种配置的两倍。 415 | 416 | 417 | ### Tuning for Capacity(调优系统容量) 418 | 419 | 420 | 假设需要将软件部署到服务器上(commodity-class hardware), 配置为 `4核10G`。这样的话, 系统容量的要求就变成: 最大的堆内存空间不能超过 `8GB`。有了这个需求, 我们需要调整为第三套配置进行测试: 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 |
堆内存大小(Heap)GC算法(GC Algorithm)有效时间比(Useful work)最长停顿时间(Longest pause)
-Xmx12g-XX:+UseConcMarkSweepGC89.8%560 ms
-Xmx12g-XX:+UseParallelGC91.5%1,104 ms
-Xmx8g-XX:+UseConcMarkSweepGC66.3%1,610 ms
454 | 455 | 456 | 457 | 程序可以通过如下参数执行: 458 | 459 | 460 | java -Xmx8g -XX:+UseConcMarkSweepGC Producer 461 | 462 | 463 | 测试结果是延迟大幅增长, 吞吐量同样大幅降低: 464 | 465 | 466 | - 现在,GC占用了更多的CPU资源, 这个配置只有 `66.3%` 的有效CPU时间。因此,这个配置让吞吐量从最好的情况 **13,176,000 操作/小时** 下降到 **不足 9,547,200次操作/小时**. 467 | - 最坏情况下的延迟变成了 **1,610 ms**, 而不再是 **560ms**。 468 | 469 | 470 | 通过对这三个维度的介绍, 你应该了解, 不是简单的进行“性能(performance)”优化, 而是需要从三种不同的维度来进行考虑, 测量, 并调优延迟和吞吐量, 此外还需要考虑系统容量的约束。 471 | 472 | 473 | 原文链接: [GC Tuning: Basics](https://plumbr.eu/handbook/gc-tuning) 474 | 475 | -------------------------------------------------------------------------------- /06_01_JMX-view.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_01_JMX-view.png -------------------------------------------------------------------------------- /06_02_JMX-view-Mbean.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_02_JMX-view-Mbean.png -------------------------------------------------------------------------------- /06_03_jvmsualvm-garbage-collection-monitoring.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_03_jvmsualvm-garbage-collection-monitoring.png -------------------------------------------------------------------------------- /06_04_gcviewer-screenshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_04_gcviewer-screenshot.png -------------------------------------------------------------------------------- /06_05_gviewer-screenshot-pause.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_05_gviewer-screenshot-pause.png -------------------------------------------------------------------------------- /06_06_gcviewer-screenshot-eventdetails.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_06_gcviewer-screenshot-eventdetails.png -------------------------------------------------------------------------------- /06_07_01_trace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_07_01_trace.png -------------------------------------------------------------------------------- /06_07_jvisualvm-top-objects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_07_jvisualvm-top-objects.png -------------------------------------------------------------------------------- /06_08_jvisualvm-allocation-traces.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/06_08_jvisualvm-allocation-traces.png -------------------------------------------------------------------------------- /06_GC_Tuning_Tooling_CN.md: -------------------------------------------------------------------------------- 1 | # 6. GC 调优(工具篇) 2 | 3 | 4 | 进行GC性能调优时, 需要明确了解, 当前的GC行为对系统和用户有多大的影响。有多种监控GC的工具和方法, 本章将逐一介绍常用的工具。 5 | 6 | 7 | JVM 在程序执行的过程中, 提供了GC行为的原生数据。那么, 我们就可以利用这些原生数据来生成各种报告。原生数据(*raw data*) 包括: 8 | 9 | 10 | - 各个内存池的当前使用情况, 11 | - 各个内存池的总容量, 12 | - 每次GC暂停的持续时间, 13 | - GC暂停在各个阶段的持续时间。 14 | 15 | 16 | 可以通过这些数据算出各种指标, 例如: 程序的内存分配率, 提升率等等。本章主要介绍如何获取原生数据。 后续的章节将对重要的派生指标(derived metrics)展开讨论, 并引入GC性能相关的话题。 17 | 18 | 19 | ## JMX API 20 | 21 | 22 | 从 JVM 运行时获取GC行为数据, 最简单的办法是使用标准 [JMX API 接口](https://docs.oracle.com/javase/tutorial/jmx/index.html). JMX是获取 JVM内部运行时状态信息 的标准API. 可以编写程序代码, 通过 JMX API 来访问本程序所在的JVM，也可以通过JMX客户端执行(远程)访问。 23 | 24 | 25 | 最常见的 JMX客户端是 [JConsole](http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html) 和 [JVisualVM](http://docs.oracle.com/javase/7/docs/technotes/tools/share/jvisualvm.html) (可以安装各种插件,十分强大)。两个工具都是标准JDK的一部分, 而且很容易使用. 如果使用的是 JDK 7u40 及更高版本, 还可以使用另一个工具: [Java Mission Control](http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html)( 大致翻译为 Java控制中心, `jmc.exe`)。 26 | 27 | > JVisualVM安装MBeans插件的步骤: 通过 工具(T) -- 插件(G) -- 可用插件 -- 勾选VisualVM-MBeans -- 安装 -- 下一步 -- 等待安装完成...... 其他插件的安装过程基本一致。 28 | 29 | 30 | 所有 JMX客户端都是独立的程序,可以连接到目标JVM上。目标JVM可以在本机, 也可能是远端JVM. 如果要连接远端JVM, 则目标JVM启动时必须指定特定的环境变量,以开启远程JMX连接/以及端口号。 示例如下: 31 | 32 | 33 | java -Dcom.sun.management.jmxremote.port=5432 com.yourcompany.YourApp 34 | 35 | 36 | 在此处, JVM 打开端口`5432`以支持JMX连接。 37 | 38 | 39 | 通过 JVisualVM 连接到某个JVM以后, 切换到 MBeans 标签, 展开 “java.lang/GarbageCollector” . 就可以看到GC行为信息, 下图是 JVisualVM 中的截图: 40 | 41 | 42 | ![](06_01_JMX-view.png) 43 | 44 | 45 | 46 | 下图是Java Mission Control 中的截图: 47 | 48 | ![](06_02_JMX-view-Mbean.png) 49 | 50 | 51 | 52 | 从以上截图中可以看到两款垃圾收集器。其中一款负责清理年轻代(**PS Scavenge**)，另一款负责清理老年代(**PS MarkSweep**); 列表中显示的就是垃圾收集器的名称。可以看到 , jmc 的功能和展示数据的方式更强大。 53 | 54 | 55 | 对所有的垃圾收集器, 通过 JMX API 获取的信息包括: 56 | 57 | 58 | - **CollectionCount** : 垃圾收集器执行的GC总次数, 59 | - **CollectionTime**: 收集器运行时间的累计。这个值等于所有GC事件持续时间的总和, 60 | - **LastGcInfo**: 最近一次GC事件的详细信息。包括 GC事件的持续时间(duration), 开始时间(startTime) 和 结束时间(endTime), 以及各个内存池在最近一次GC之前和之后的使用情况, 61 | - **MemoryPoolNames**: 各个内存池的名称, 62 | - **Name**: 垃圾收集器的名称 63 | - **ObjectName**: 由JMX规范定义的 MBean的名字,, 64 | - **Valid**: 此收集器是否有效。本人只见过 "`true`"的情况 (^_^) 65 | 66 | 67 | 根据经验, 这些信息对GC的性能来说,不能得出什么结论. 只有编写程序, 获取GC相关的 JMX 信息来进行统计和分析。 在下文可以看到, 一般也不怎么关注 MBean , 但 MBean 对于理解GC的原理倒是挺有用的。 68 | 69 | 70 | ## JVisualVM 71 | 72 | 73 | [JVisualVM](http://docs.oracle.com/javase/7/docs/technotes/tools/share/jvisualvm.html) 工具的 “[VisualGC](http://www.oracle.com/technetwork/java/visualgc-136680.html)” 插件提供了基本的 JMX客户端功能, 还实时显示出 GC事件以及各个内存空间的使用情况。 74 | 75 | 76 | Visual GC 插件常用来监控本机运行的Java程序, 比如开发者和性能调优专家经常会使用此插件, 以快速获取程序运行时的GC信息。 77 | 78 | 79 | ![](06_03_jvmsualvm-garbage-collection-monitoring.png) 80 | 81 | 82 | 左侧的图表展示了各个内存池的使用情况: Metaspace/永久代, 老年代, Eden区以及两个存活区。 83 | 84 | 85 | 在右边, 顶部的两个图表与 GC无关, 显示的是 JIT编译时间 和 类加载时间。下面的6个图显示的是内存池的历史记录, 每个内存池的GC次数,GC总时间, 以及最大值，峰值, 当前使用情况。 86 | 87 | 88 | 再下面是 HistoGram, 显示了年轻代对象的年龄分布。至于对象的年龄监控(objects tenuring monitoring), 本章不进行讲解。 89 | 90 | 91 | 与纯粹的JMX工具相比, VisualGC 插件提供了更友好的界面, 如果没有其他趁手的工具, 请选择VisualGC. 本章接下来会介绍其他工具, 这些工具可以提供更多的信息, 以及更好的视角. 当然, 在“Profilers(分析器)”一节中，也会介绍 JVisualVM 的适用场景 —— 如: 分配分析(allocation profiling), 所以我们绝不会贬低哪一款工具, 关键还得看实际情况。 92 | 93 | 94 | ## jstat 95 | 96 | 97 | [jstat](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html) 也是标准JDK提供的一款监控工具(Java Virtual Machine statistics monitoring tool),可以统计各种指标。既可以连接到本地JVM,也可以连到远程JVM. 查看支持的指标和对应选项可以执行 “`jstat -options`” 。例如: 98 | 99 | 100 | +-----------------+---------------------------------------------------------------+ 101 | | Option | Displays... | 102 | +-----------------+---------------------------------------------------------------+ 103 | |class | Statistics on the behavior of the class loader | 104 | |compiler | Statistics on the behavior of the HotSpot Just-In-Time com- | 105 | | | piler | 106 | |gc | Statistics on the behavior of the garbage collected heap | 107 | |gccapacity | Statistics of the capacities of the generations and their | 108 | | | corresponding spaces. | 109 | |gccause | Summary of garbage collection statistics (same as -gcutil), | 110 | | | with the cause of the last and current (if applicable) | 111 | | | garbage collection events. | 112 | |gcnew | Statistics of the behavior of the new generation. | 113 | |gcnewcapacity | Statistics of the sizes of the new generations and its corre- | 114 | | | sponding spaces. | 115 | |gcold | Statistics of the behavior of the old and permanent genera- | 116 | | | tions. | 117 | |gcoldcapacity | Statistics of the sizes of the old generation. | 118 | |gcpermcapacity | Statistics of the sizes of the permanent generation. | 119 | |gcutil | Summary of garbage collection statistics. | 120 | |printcompilation | Summary of garbage collection statistics. | 121 | +-----------------+---------------------------------------------------------------+ 122 | 123 | 124 | 125 | jstat 对于快速确定GC行为是否健康非常有用。启动方式为: “`jstat -gc -t PID 1s`” , 其中,PID 就是要监视的Java进程ID。可以通过 `jps` 命令查看正在运行的Java进程列表。 126 | 127 | 128 | jps 129 | 130 | jstat -gc -t 2428 1s 131 | 132 | 133 | 以上命令的结果, 是 jstat 每秒向标准输出输出一行新内容, 比如: 134 | 135 | 136 | Timestamp S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 137 | 200.0 8448.0 8448.0 8448.0 0.0 67712.0 67712.0 169344.0 169344.0 21248.0 20534.3 3072.0 2807.7 34 0.720 658 133.684 134.404 138 | 201.0 8448.0 8448.0 8448.0 0.0 67712.0 67712.0 169344.0 169343.2 21248.0 20534.3 3072.0 2807.7 34 0.720 662 134.712 135.432 139 | 202.0 8448.0 8448.0 8102.5 0.0 67712.0 67598.5 169344.0 169343.6 21248.0 20534.3 3072.0 2807.7 34 0.720 667 135.840 136.559 140 | 203.0 8448.0 8448.0 8126.3 0.0 67712.0 67702.2 169344.0 169343.6 21248.0 20547.2 3072.0 2807.7 34 0.720 669 136.178 136.898 141 | 204.0 8448.0 8448.0 8126.3 0.0 67712.0 67702.2 169344.0 169343.6 21248.0 20547.2 3072.0 2807.7 34 0.720 669 136.178 136.898 142 | 205.0 8448.0 8448.0 8134.6 0.0 67712.0 67712.0 169344.0 169343.5 21248.0 20547.2 3072.0 2807.7 34 0.720 671 136.234 136.954 143 | 206.0 8448.0 8448.0 8134.6 0.0 67712.0 67712.0 169344.0 169343.5 21248.0 20547.2 3072.0 2807.7 34 0.720 671 136.234 136.954 144 | 207.0 8448.0 8448.0 8154.8 0.0 67712.0 67712.0 169344.0 169343.5 21248.0 20547.2 3072.0 2807.7 34 0.720 673 136.289 137.009 145 | 208.0 8448.0 8448.0 8154.8 0.0 67712.0 67712.0 169344.0 169343.5 21248.0 20547.2 3072.0 2807.7 34 0.720 673 136.289 137.009 146 | 147 | 148 | 149 | 稍微解释一下上面的内容。参考 [jstat manpage](http://www.manpagez.com/man/1/jstat/) , 我们可以知道: 150 | 151 | 152 | - jstat 连接到 JVM 的时间, 是JVM启动后的 200秒。此信息从第一行的 “**Timestamp**” 列得知。继续看下一行, jstat 每秒钟从JVM 接收一次信息, 也就是命令行参数中 "`1s`" 的含义。 153 | - 从第一行的 “**YGC**” 列得知年轻代共执行了34次GC, 由 “**FGC**” 列得知整个堆内存已经执行了 658次 full GC。 154 | - 年轻代的GC耗时总共为 `0.720 秒`, 显示在“**YGCT**” 这一列。 155 | - Full GC 的总计耗时为 `133.684 秒`, 由“**FGCT**”列得知。 这立马就吸引了我们的目光, 总的JVM 运行时间只有 200 秒, **但其中有 66% 的部分被 Full GC 消耗了**。 156 | 157 | 158 | 再看下一行, 问题就更明显了。 159 | 160 | 161 | - 在接下来的一秒内共执行了 4 次 Full GC。参见 "**FGC**" 列. 162 | - 这4次 Full GC 暂停占用了差不多 1秒的时间(根据 **FGCT**列的差得知)。与第一行相比, Full GC 耗费了`928 毫秒`, 即 `92.8%` 的时间。 163 | - 根据 “**OC** 和 “**OU**” 列得知, **整个老年代的空间**为 `169,344.0 KB` (“OC“), 在 4 次 Full GC 后依然占用了 `169,344.2 KB` (“OU“)。用了 `928ms` 的时间却只释放了 800 字节的内存, 怎么看都觉得很不正常。 164 | 165 | 166 | 只看这两行的内容, 就知道程序出了很严重的问题。继续分析下一行, 可以确定问题依然存在,而且变得更糟。 167 | 168 | 169 | JVM几乎完全卡住了(stalled), 因为GC占用了90%以上的计算资源。GC之后, 所有的老代空间仍然还在占用。事实上, 程序在一分钟以后就挂了, 抛出了 “[java.lang.OutOfMemoryError: GC overhead limit exceeded](https://plumbr.eu/outofmemoryerror/gc-overhead-limit-exceeded)” 错误。 170 | 171 | 172 | 可以看到, 通过 jstat 能很快发现对JVM健康极为不利的GC行为。一般来说, 只看 jstat 的输出就能快速发现以下问题: 173 | 174 | 175 | - 最后一列 “**GCT**”, 与JVM的总运行时间 “**Timestamp**” 的比值, 就是GC 的开销。如果每一秒内, "**GCT**" 的值都会明显增大, 与总运行时间相比, 就暴露出GC开销过大的问题. 不同系统对GC开销有不同的容忍度, 由性能需求决定, 一般来讲, 超过 `10%` 的GC开销都是有问题的。 176 | - “**YGC**” 和 “**FGC**” 列的快速变化往往也是有问题的征兆。频繁的GC暂停会累积,并导致更多的线程停顿(stop-the-world pauses), 进而影响吞吐量。 177 | - 如果看到 “**OU**” 列中,老年代的使用量约等于老年代的最大容量(**OC**), 并且不降低的话, 就表示虽然执行了老年代GC, 但基本上属于无效GC。 178 | 179 | 180 | ## GC日志(GC logs) 181 | 182 | 183 | 通过日志内容也可以得到GC相关的信息。因为GC日志模块内置于JVM中, 所以日志中包含了对GC活动最全面的描述。 这就是事实上的标准, 可作为GC性能评估和优化的最真实数据来源。 184 | 185 | 186 | GC日志一般输出到文件之中, 是纯 text 格式的, 当然也可以打印到控制台。有多个可以控制GC日志的JVM参数。例如,可以打印每次GC的持续时间, 以及程序暂停时间(`-XX:+PrintGCApplicationStoppedTime`), 还有GC清理了多少引用类型(`-XX:+PrintReferenceGC`)。 187 | 188 | 189 | 要打印GC日志, 需要在启动脚本中指定以下参数: 190 | 191 | 192 | -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc: 193 | 194 | 195 | 以上参数指示JVM: 将所有GC事件打印到日志文件中, 输出每次GC的日期和时间戳。不同GC算法输出的内容略有不同. ParallelGC 输出的日志类似这样: 196 | 197 | 198 | 199.879: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1473386 secs] [Times: user=0.43 sys=0.01, real=0.15 secs] 199 | 200.027: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1567794 secs] [Times: user=0.41 sys=0.00, real=0.16 secs] 200 | 200.184: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1621946 secs] [Times: user=0.43 sys=0.00, real=0.16 secs] 201 | 200.346: [Full GC (Ergonomics) [PSYoungGen: 64000K->63998K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1547695 secs] [Times: user=0.41 sys=0.00, real=0.15 secs] 202 | 200.502: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1563071 secs] [Times: user=0.42 sys=0.01, real=0.16 secs] 203 | 200.659: [Full GC (Ergonomics) [PSYoungGen: 64000K->63999K(74240K)] [ParOldGen: 169318K->169318K(169472K)] 233318K->233317K(243712K), [Metaspace: 20427K->20427K(1067008K)], 0.1538778 secs] [Times: user=0.42 sys=0.00, real=0.16 secs] 204 | 205 | 在 “[04. GC算法:实现篇](http://blog.csdn.net/renfufei/article/details/54885190)” 中详细介绍了这些格式, 如果对此不了解, 可以先阅读该章节。 206 | 207 | 分析以上日志内容, 可以得知: 208 | 209 | 210 | - 这部分日志截取自JVM启动后200秒左右。 211 | - 日志片段中显示, 在`780毫秒`以内, 因为垃圾回收 导致了5次 Full GC 暂停(去掉第六次暂停,这样更精确一些)。 212 | - 这些暂停事件的总持续时间是 `777毫秒`, 占总运行时间的 **99.6%**。 213 | - 在GC完成之后, 几乎所有的老年代空间(`169,472 KB`)依然被占用(`169,318 KB`)。 214 | 215 | 216 | 通过日志信息可以确定, 该应用的GC情况非常糟糕。JVM几乎完全停滞, 因为GC占用了超过`99%`的CPU时间。 而GC的结果是, 老年代空间仍然被占满, 这进一步肯定了我们的结论。 示例程序和jstat 小节中的是同一个, 几分钟之后系统就挂了, 抛出 “[java.lang.OutOfMemoryError: GC overhead limit exceeded](https://plumbr.eu/outofmemoryerror/gc-overhead-limit-exceeded)” 错误, 不用说, 问题是很严重的. 217 | 218 | 219 | 从此示例可以看出, GC日志对监控GC行为和JVM是否处于健康状态非常有用。一般情况下, 查看 GC 日志就可以快速确定以下症状: 220 | 221 | 222 | - GC开销太大。如果GC暂停的总时间很长, 就会损害系统的吞吐量。不同的系统允许不同比例的GC开销, 但一般认为, 正常范围在 `10%` 以内。 223 | - 极个别的GC事件暂停时间过长。当某次GC暂停时间太长, 就会影响系统的延迟指标. 如果延迟指标规定交易必须在 `1,000 ms`内完成, 那就不能容忍任何超过 `1000毫秒`的GC暂停。 224 | - 老年代的使用量超过限制。如果老年代空间在 Full GC 之后仍然接近全满, 那么GC就成为了性能瓶颈, 可能是内存太小, 也可能是存在内存泄漏。这种症状会让GC的开销暴增。 225 | 226 | 227 | 可以看到,GC日志中的信息非常详细。但除了这些简单的小程序, 生产系统一般都会生成大量的GC日志, 纯靠人工是很难阅读和进行解析的。 228 | 229 | 230 | ## GCViewer 231 | 232 | 233 | 我们可以自己编写解析器, 来将庞大的GC日志解析为直观易读的图形信息。 但很多时候自己写程序也不是个好办法, 因为各种GC算法的复杂性, 导致日志信息格式互相之间不太兼容。那么神器来了: [GCViewer](https://github.com/chewiebug/GCViewer)。 234 | 235 | 236 | [GCViewer](https://github.com/chewiebug/GCViewer) 是一款开源的GC日志分析工具。项目的 GitHub 主页对各项指标进行了完整的描述. 下面我们介绍最常用的一些指标。 237 | 238 | 239 | 第一步是获取GC日志文件。这些日志文件要能够反映系统在性能调优时的具体场景. 假若运营部门(operational department)反馈: 每周五下午,系统就运行缓慢, 不管GC是不是主要原因, 分析周一早晨的日志是没有多少意义的。 240 | 241 | 242 | 获取到日志文件之后, 就可以用 GCViewer 进行分析, 大致会看到类似下面的图形界面: 243 | 244 | 245 | ![](06_04_gcviewer-screenshot.png) 246 | 247 | 248 | 使用的命令行大致如下: 249 | 250 | java -jar gcviewer_1.3.4.jar gc.log 251 | 252 | 253 | 当然, 如果不想打开程序界面,也可以在后面加上其他参数,直接将分析结果输出到文件。 254 | 255 | 命令大致如下: 256 | 257 | java -jar gcviewer_1.3.4.jar gc.log summary.csv chart.png 258 | 259 | 260 | 以上命令将信息汇总到当前目录下的 Excel 文件 `summary.csv` 之中, 将图形信息保存为 `chart.png` 文件。 261 | 262 | 点击下载: [gcviewer的jar包及使用示例](http://download.csdn.net/detail/renfufei/9753654) 。 263 | 264 | 265 | 上图中, Chart 区域是对GC事件的图形化展示。包括各个内存池的大小和GC事件。上图中, 只有两个可视化指标: 蓝色线条表示堆内存的使用情况, 黑色的Bar则表示每次GC暂停时间的长短。 266 | 267 | 268 | 从图中可以看到, 内存使用量增长很快。一分钟左右就达到了堆内存的最大值. 堆内存几乎全部被消耗, 不能顺利分配新对象, 并引发频繁的 Full GC 事件. 这说明程序可能存在内存泄露, 或者启动时指定的内存空间不足。 269 | 270 | 271 | 从图中还可以看到 GC暂停的频率和持续时间。`30秒`之后, GC几乎不间断地运行,最长的暂停时间超过`1.4秒`。 272 | 273 | 274 | 在右边有三个选项卡。“**`Summary`**(摘要)” 中比较有用的是 “`Throughput`”(吞吐量百分比) 和 “`Number of GC pauses`”(GC暂停的次数), 以及“`Number of full GC pauses`”(Full GC 暂停的次数). 吞吐量显示了有效工作的时间比例, 剩下的部分就是GC的消耗。 275 | 276 | 277 | 以上示例中的吞吐量为 **`6.28%`**。这意味着有 **`93.72%`** 的CPU时间用在了GC上面. 很明显系统所面临的情况很糟糕 —— 宝贵的CPU时间没有用于执行实际工作, 而是在试图清理垃圾。 278 | 279 | 280 | 下一个有意思的地方是“**Pause**”(暂停)选项卡: 281 | 282 | 283 | ![](06_05_gviewer-screenshot-pause.png) 284 | 285 | 286 | “`Pause`” 展示了GC暂停的总时间,平均值,最小值和最大值, 并且将 total 与minor/major 暂停分开统计。如果要优化程序的延迟指标, 这些统计可以很快判断出暂停时间是否过长。另外, 我们可以得出明确的信息: 累计暂停时间为 `634.59 秒`, GC暂停的总次数为 `3,938 次`, 这在`11分钟/660秒`的总运行时间里那不是一般的高。 287 | 288 | 289 | 更详细的GC暂停汇总信息, 请查看主界面中的 “**Event details**” 标签: 290 | 291 | 292 | ![](06_06_gcviewer-screenshot-eventdetails.png) 293 | 294 | 295 | 从“**Event details**” 标签中, 可以看到日志中所有重要的GC事件汇总: `普通GC停顿` 和 `Full GC 停顿次数`, 以及`并发执行数`, `非 stop-the-world 事件`等。此示例中, 可以看到一个明显的地方, Full GC 暂停严重影响了吞吐量和延迟, 依据是: `3,928 次 Full GC`, 暂停了`634秒`。 296 | 297 | 298 | 可以看到, GCViewer 能用图形界面快速展现异常的GC行为。一般来说, 图像化信息能迅速揭示以下症状: 299 | 300 | 301 | - 低吞吐量。当应用的吞吐量下降到不能容忍的地步时, 有用工作的总时间就大量减少. 具体有多大的 “容忍度”(tolerable) 取决于具体场景。按照经验, 低于 90% 的有效时间就值得警惕了, 可能需要好好优化下GC。 302 | - 单次GC的暂停时间过长。只要有一次GC停顿时间过长,就会影响程序的延迟指标. 例如, 延迟需求规定必须在 1000 ms以内完成交易, 那就不能容忍任何一次GC暂停超过1000毫秒。 303 | - 堆内存使用率过高。如果老年代空间在 Full GC 之后仍然接近全满, 程序性能就会大幅降低, 可能是资源不足或者内存泄漏。这种症状会对吞吐量产生严重影响。 304 | 305 | 306 | 业界良心 —— 图形化展示的GC日志信息绝对是我们重磅推荐的。不用去阅读冗长而又复杂的GC日志,通过容易理解的图形, 也可以得到同样的信息。 307 | 308 | 309 | ## 分析器(Profilers) 310 | 311 | 312 | 下面介绍分析器([profilers](http://zeroturnaround.com/rebellabs/developer-productivity-report-2015-java-performance-survey-results/3/), Oracle官方翻译是:`抽样器`)。相对于前面的工具, 分析器只关心GC中的一部分领域. 本节我们也只关注分析器相关的GC功能。 313 | 314 | 315 | 首先警告 —— 不要认为分析器适用于所有的场景。分析器有时确实作用很大, 比如检测代码中的CPU热点时。但某些情况使用分析器不一定是个好方案。 316 | 317 | 318 | 对GC调优来说也是一样的。要检测是否因为GC而引起延迟或吞吐量问题时, 不需要使用分析器. 前面提到的工具( `jstat` 或 原生/可视化GC日志)就能更好更快地检测出是否存在GC问题. 特别是从生产环境中收集性能数据时, 最好不要使用分析器, 因为性能开销非常大。 319 | 320 | 321 | 如果确实需要对GC进行优化, 那么分析器就可以派上用场了, 可以对 Object 的创建信息一目了然. 换个角度看, 如果GC暂停的原因不在某个内存池中, 那就只会是因为创建对象太多了。 所有分析器都能够跟踪对象分配(via allocation profiling), 根据内存分配的轨迹, 让你知道 **实际驻留在内存中的是哪些对象**。 322 | 323 | 324 | 分配分析能定位到在哪个地方创建了大量的对象. 使用分析器辅助进行GC调优的好处是, 能确定哪种类型的对象最占用内存, 以及哪些线程创建了最多的对象。 325 | 326 | 327 | 下面我们通过实例介绍3种分配分析器: **`hprof`**, **`JVisualV`M** 和 **`AProf`**。实际上还有很多分析器可供选择, 有商业产品,也有免费工具, 但其功能和应用基本上都是类似的。 328 | 329 | 330 | ### hprof 331 | 332 | 333 | [hprof 分析器](http://docs.oracle.com/javase/8/docs/technotes/samples/hprof.html)内置于JDK之中。 在各种环境下都可以使用, 一般优先使用这款工具。 334 | 335 | 336 | 要让 `hprof` 和程序一起运行, 需要修改启动脚本, 类似这样: 337 | 338 | 339 | java -agentlib:hprof=heap=sites com.yourcompany.YourApplication 340 | 341 | 342 | 在程序退出时,会将分配信息dump(转储)到工作目录下的 `java.hprof.txt` 文件中。使用文本编辑器打开, 并搜索 “**SITES BEGIN**” 关键字, 可以看到: 343 | 344 | 345 | SITES BEGIN (ordered by live bytes) Tue Dec 8 11:16:15 2015 346 | percent live alloc'ed stack class 347 | rank self accum bytes objs bytes objs trace name 348 | 1 64.43% 4.43% 8370336 20121 27513408 66138 302116 int[] 349 | 2 3.26% 88.49% 482976 20124 1587696 66154 302104 java.util.ArrayList 350 | 3 1.76% 88.74% 241704 20121 1587312 66138 302115 eu.plumbr.demo.largeheap.ClonableClass0006 351 | ... 部分省略 ... 352 | 353 | SITES END 354 | 355 | 356 | 从以上片段可以看到, allocations 是根据每次创建的对象数量来排序的。第一行显示所有对象中有 **`64.43%`** 的对象是整型数组(`int[]`), 在标识为 `302116` 的位置创建。搜索 “**TRACE 302116**” 可以看到: 357 | 358 | 359 | TRACE 302116: 360 | eu.plumbr.demo.largeheap.ClonableClass0006.(GeneratorClass.java:11) 361 | sun.reflect.GeneratedConstructorAccessor7.newInstance(:Unknown line) 362 | sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 363 | java.lang.reflect.Constructor.newInstance(Constructor.java:422) 364 | 365 | 366 | 367 | 现在, 知道有 `64.43%` 的对象是整数数组, 在 `ClonableClass0006` 类的构造函数中, 第11行的位置, 接下来就可以优化代码, 以减少GC的压力。 368 | 369 | 370 | ### Java VisualVM 371 | 372 | 373 | 本章前面的第一部分, 在监控 JVM 的GC行为工具时介绍了 JVisualVM , 本节介绍其在分配分析上的应用。 374 | 375 | 376 | JVisualVM 通过GUI的方式连接到正在运行的JVM。 连接上目标JVM之后 : 377 | 378 | 379 | 1. 打开 “工具” --> “选项” 菜单, 点击 **性能分析(Profiler)** 标签, 新增配置, 选择 Profiler 内存, 确保勾选了 “Record allocations stack traces”(记录分配栈跟踪)。 380 | 2. 勾选 “Settings”(设置) 复选框, 在内存设置标签下,修改预设配置。 381 | 3. 点击 “Memory”(内存) 按钮开始进行内存分析。 382 | 4. 让程序运行一段时间,以收集关于对象分配的足够信息。 383 | 5. 单击下方的 “Snapshot”(快照) 按钮。可以获取收集到的快照信息。 384 | 385 | 386 | ![](06_07_01_trace.png) 387 | 388 | 389 | 完成上面的步骤后, 可以得到类似这样的信息: 390 | 391 | 392 | ![](06_07_jvisualvm-top-objects.png) 393 | 394 | 395 | 上图按照每个类被创建的对象数量多少来排序。看第一行可以知道, 创建的最多的对象是 `int[]` 数组. 鼠标右键单击这行, 就可以看到这些对象都在哪些地方创建的: 396 | 397 | 398 | ![](06_08_jvisualvm-allocation-traces.png) 399 | 400 | 401 | 与 `hprof` 相比, JVisualVM 更加容易使用 —— 比如上面的截图中, 在一个地方就可以看到所有`int[]` 的分配信息, 所以多次在同一处代码进行分配的情况就很容易发现。 402 | 403 | 404 | ### AProf 405 | 406 | 407 | 最重要的一款分析器,是由 Devexperts 开发的 **[AProf](https://code.devexperts.com/display/AProf/About+Aprof)**。 内存分配分析器 AProf 也被打包为 Java agent 的形式。 408 | 409 | 410 | 用 AProf 分析应用程序, 需要修改 JVM 启动脚本,类似这样: 411 | 412 | 413 | java -javaagent:/path-to/aprof.jar com.yourcompany.YourApplication 414 | 415 | 416 | 重启应用之后, 工作目录下会生成一个 `aprof.txt` 文件。此文件每分钟更新一次, 包含这样的信息: 417 | 418 | 419 | ======================================================================================================================== 420 | TOTAL allocation dump for 91,289 ms (0h01m31s) 421 | Allocated 1,769,670,584 bytes in 24,868,088 objects of 425 classes in 2,127 locations 422 | ======================================================================================================================== 423 | 424 | Top allocation-inducing locations with the data types allocated from them 425 | ------------------------------------------------------------------------------------------------------------------------ 426 | eu.plumbr.demo.largeheap.ManyTargetsGarbageProducer.newRandomClassObject: 1,423,675,776 (80.44%) bytes in 17,113,721 (68.81%) objects (avg size 83 bytes) 427 | int[]: 711,322,976 (40.19%) bytes in 1,709,911 (6.87%) objects (avg size 416 bytes) 428 | char[]: 369,550,816 (20.88%) bytes in 5,132,759 (20.63%) objects (avg size 72 bytes) 429 | java.lang.reflect.Constructor: 136,800,000 (7.73%) bytes in 1,710,000 (6.87%) objects (avg size 80 bytes) 430 | java.lang.Object[]: 41,079,872 (2.32%) bytes in 1,710,712 (6.87%) objects (avg size 24 bytes) 431 | java.lang.String: 41,063,496 (2.32%) bytes in 1,710,979 (6.88%) objects (avg size 24 bytes) 432 | java.util.ArrayList: 41,050,680 (2.31%) bytes in 1,710,445 (6.87%) objects (avg size 24 bytes) 433 | ... cut for brevity ... 434 | 435 | 436 | 437 | 上面的输出是按照 `size` 进行排序的。可以看出, `80.44%` 的 bytes 和 `68.81%` 的 objects 是在 `ManyTargetsGarbageProducer.newRandomClassObject()` 方法中分配的。 其中, **int[]** 数组占用了 `40.19%` 的内存, 是最大的一个。 438 | 439 | 440 | 继续往下看, 会发现 `allocation traces`(分配痕迹)相关的内容, 也是以 allocation size 排序的: 441 | 442 | 443 | Top allocated data types with reverse location traces 444 | ------------------------------------------------------------------------------------------------------------------------ 445 | int[]: 725,306,304 (40.98%) bytes in 1,954,234 (7.85%) objects (avg size 371 bytes) 446 | eu.plumbr.demo.largeheap.ClonableClass0006.: 38,357,696 (2.16%) bytes in 92,206 (0.37%) objects (avg size 416 bytes) 447 | java.lang.reflect.Constructor.newInstance: 38,357,696 (2.16%) bytes in 92,206 (0.37%) objects (avg size 416 bytes) 448 | eu.plumbr.demo.largeheap.ManyTargetsGarbageProducer.newRandomClassObject: 38,357,280 (2.16%) bytes in 92,205 (0.37%) objects (avg size 416 bytes) 449 | java.lang.reflect.Constructor.newInstance: 416 (0.00%) bytes in 1 (0.00%) objects (avg size 416 bytes) 450 | ... cut for brevity ... 451 | 452 | 453 | 454 | 可以看到, `int[]` 数组的分配, 在 `ClonableClass0006` 构造函数中继续增大。 455 | 456 | 457 | 和其他工具一样, `AProf` 揭露了 分配的大小以及位置信息(`allocation size and locations`), 从而能够快速找到最耗内存的部分。在我们看来, **AProf** 是最有用的分配分析器, 因为它只专注于内存分配, 所以做得最好。 当然, 这款工具是开源免费的, 资源开销也最小。 458 | 459 | 460 | 原文链接: [GC Tuning: Tooling](https://plumbr.eu/handbook/gc-tuning-measuring) 461 | 462 | -------------------------------------------------------------------------------- /07_01_how-java-garbage-collection-works.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/07_01_how-java-garbage-collection-works.png -------------------------------------------------------------------------------- /07_GC_Tuning_In_Practice_CN.md: -------------------------------------------------------------------------------- 1 | # 7. GC 调优(实战篇) 2 | 3 | 本章介绍导致GC性能问题的典型情况。相关示例都来源于生产环境, 为演示需要做了一定长度的精简。 4 | 5 | > **说明**: `Allocation Rate`, 翻译为`分配速率`, 而不是分配率; 因为不是百分比,而是单位时间内分配的量; 6 | > 7 | > 同理, `Promotion Rate` 翻译为 `提升速率`; 8 | 9 | 10 | 11 | 12 | ## 高分配速率(High Allocation Rate) 13 | 14 | 15 | 分配速率(`Allocation rate`)表示单位时间内分配的内存量。通常使用 `MB/sec`作为单位, 也可以使用 `PB/year` 等。 16 | 17 | 18 | 分配速率过高就会严重影响程序的性能。在JVM中会导致巨大的GC开销。 19 | 20 | 21 | ### 如何测量分配速率? 22 | 23 | 24 | 指定JVM参数: `-XX:+PrintGCDetails -XX:+PrintGCTimeStamps` , 通过GC日志来计算分配速率. GC日志如下所示: 25 | 26 | 27 | 0.291: [GC (Allocation Failure) 28 | [PSYoungGen: 33280K->5088K(38400K)] 29 | 33280K->24360K(125952K), 0.0365286 secs] 30 | [Times: user=0.11 sys=0.02, real=0.04 secs] 31 | 0.446: [GC (Allocation Failure) 32 | [PSYoungGen: 38368K->5120K(71680K)] 33 | 57640K->46240K(159232K), 0.0456796 secs] 34 | [Times: user=0.15 sys=0.02, real=0.04 secs] 35 | 0.829: [GC (Allocation Failure) 36 | [PSYoungGen: 71680K->5120K(71680K)] 37 | 112800K->81912K(159232K), 0.0861795 secs] 38 | [Times: user=0.23 sys=0.03, real=0.09 secs] 39 | 40 | 41 | 42 | 计算 `上一次垃圾收集之后`,与`下一次GC开始之前`的年轻代使用量, 两者的差值除以时间,就是分配速率。 通过上面的日志, 可以计算出以下信息: 43 | 44 | 45 | - JVM启动之后 `291ms`, 共创建了 `33,280 KB` 的对象。 第一次 Minor GC(小型GC) 完成后, 年轻代中还有 `5,088 KB` 的对象存活。 46 | - 在启动之后 `446 ms`, 年轻代的使用量增加到 `38,368 KB`, 触发第二次GC, 完成后年轻代的使用量减少到 `5,120 KB`。 47 | - 在启动之后 `829 ms`, 年轻代的使用量为 `71,680 KB`, GC后变为 `5,120 KB`。 48 | 49 | 50 | 可以通过年轻代的使用量来计算分配速率, 如下表所示: 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 |
EventTimeYoung beforeYoung afterAllocated duringAllocation rate
1st GC291ms33,280KB5,088KB33,280KB114MB/sec
2nd GC446ms38,368KB5,120KB33,280KB215MB/sec
3rd GC829ms71,680KB5,120KB66,560KB174MB/sec
Total829msN/AN/A133,120KB161MB/sec
99 | 100 | 101 | 102 | 通过这些信息可以知道, 在测量期间, 该程序的内存分配速率为 `161 MB/sec`。 103 | 104 | 105 | ### 分配速率的意义 106 | 107 | 108 | 分配速率的变化,会增加或降低GC暂停的频率, 从而影响吞吐量。 但只有年轻代的 [minor GC](http://blog.csdn.net/renfufei/article/details/54144385#t9) 受分配速率的影响, 老年代GC的频率和持续时间不受 **分配速率**(`allocation rate`)的直接影响, 而是受到 **提升速率**(`promotion rate`)的影响, 请参见下文。 109 | 110 | 111 | 现在我们只关心 [Minor GC](http://blog.csdn.net/renfufei/article/details/54144385#t9) 暂停, 查看年轻代的3个内存池。因为对象在 [Eden区](http://blog.csdn.net/renfufei/article/details/54144385#t3)分配, 所以我们一起来看 Eden 区的大小和分配速率的关系. 看看增加 Eden 区的容量, 能不能减少 Minor GC 暂停次数, 从而使程序能够维持更高的分配速率。 112 | 113 | 114 | 经过我们的实验, 通过参数 `-XX:NewSize`、 `-XX:MaxNewSize` 以及 `-XX:SurvivorRatio` 设置不同的 Eden 空间, 运行同一程序时, 可以发现: 115 | 116 | 117 | - Eden 空间为 `100 MB` 时, 分配速率低于 `100 MB/秒`。 118 | - 将 Eden 区增大为 `1 GB`, 分配速率也随之增长,大约等于 `200 MB/秒`。 119 | 120 | 121 | 为什么会这样? —— 因为减少GC暂停,就等价于减少了任务线程的停顿，就可以做更多工作, 也就创建了更多对象, 所以对同一应用来说, 分配速率越高越好。 122 | 123 | 124 | 在得出 “Eden区越大越好” 这个结论前, 我们注意到, 分配速率可能会,也可能不会影响程序的实际吞吐量。 吞吐量和分配速率有一定关系, 因为分配速率会影响 minor GC 暂停, 但对于总体吞吐量的影响, 还要考虑 Major GC(大型GC)暂停, 而且吞吐量的单位不是 `MB/秒`， 而是系统所处理的业务量。 125 | 126 | 127 | ### 示例 128 | 129 | 130 | 参考 [Demo程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/Boxing.java)。假设系统连接了一个外部的数字传感器。应用通过专有线程, 不断地获取传感器的值,(此处使用随机数模拟), 其他线程会调用 `processSensorValue()` 方法, 传入传感器的值来执行某些操作, : 131 | 132 | 133 | public class BoxingFailure { 134 | private static volatile Double sensorValue; 135 | 136 | private static void readSensor() { 137 | while(true) sensorValue = Math.random(); 138 | } 139 | 140 | private static void processSensorValue(Double value) { 141 | if(value != null) { 142 | //... 143 | } 144 | } 145 | } 146 | 147 | 148 | 如同类名所示, 这个Demo是模拟 boxing 的。为了 null 值判断, 使用的是包装类型 `Double`。 程序基于传感器的最新值进行计算, 但从传感器取值是一个重量级操作, 所以采用了异步方式： 一个线程不断获取新值, 计算线程则直接使用暂存的最新值, 从而避免同步等待。 149 | 150 | 151 | [Demo 程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/Boxing.java)在运行的过程中, 由于分配速率太大而受到GC的影响。下一节将确认问题, 并给出解决办法。 152 | 153 | 154 | ### 高分配速率对JVM的影响 155 | 156 | 157 | 首先，我们应该检查程序的吞吐量是否降低。如果创建了过多的临时对象, minor GC的次数就会增加。如果并发较大, 则GC可能会严重影响吞吐量。 158 | 159 | 160 | 遇到这种情况时, GC日志将会像下面这样，当然这是上面的[示例程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/Boxing.java) 产生的GC日志。 JVM启动参数为 `-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx32m`: 161 | 162 | 163 | 2.808: [GC (Allocation Failure) 164 | [PSYoungGen: 9760K->32K(10240K)], 0.0003076 secs] 165 | 2.819: [GC (Allocation Failure) 166 | [PSYoungGen: 9760K->32K(10240K)], 0.0003079 secs] 167 | 2.830: [GC (Allocation Failure) 168 | [PSYoungGen: 9760K->32K(10240K)], 0.0002968 secs] 169 | 2.842: [GC (Allocation Failure) 170 | [PSYoungGen: 9760K->32K(10240K)], 0.0003374 secs] 171 | 2.853: [GC (Allocation Failure) 172 | [PSYoungGen: 9760K->32K(10240K)], 0.0004672 secs] 173 | 2.864: [GC (Allocation Failure) 174 | [PSYoungGen: 9760K->32K(10240K)], 0.0003371 secs] 175 | 2.875: [GC (Allocation Failure) 176 | [PSYoungGen: 9760K->32K(10240K)], 0.0003214 secs] 177 | 2.886: [GC (Allocation Failure) 178 | [PSYoungGen: 9760K->32K(10240K)], 0.0003374 secs] 179 | 2.896: [GC (Allocation Failure) 180 | [PSYoungGen: 9760K->32K(10240K)], 0.0003588 secs] 181 | 182 | 183 | 很显然 minor GC 的频率太高了。这说明创建了大量的对象。另外, 年轻代在 GC 之后的使用量又很低, 也没有 full GC 发生。 种种迹象表明, GC对吞吐量造成了严重的影响。 184 | 185 | 186 | 187 | ### 解决方案 188 | 189 | 190 | 在某些情况下,只要增加年轻代的大小, 即可降低分配速率过高所造成的影响。增加年轻代空间并不会降低分配速率, 但是会减少GC的频率。如果每次GC后只有少量对象存活, minor GC 的暂停时间就不会明显增加。 191 | 192 | 193 | 运行 [示例程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/Boxing.java) 时, 增加堆内存大小,(同时也就增大了年轻代的大小), 使用的JVM参数为 `-Xmx64m`: 194 | 195 | 196 | 2.808: [GC (Allocation Failure) 197 | [PSYoungGen: 20512K->32K(20992K)], 0.0003748 secs] 198 | 2.831: [GC (Allocation Failure) 199 | [PSYoungGen: 20512K->32K(20992K)], 0.0004538 secs] 200 | 2.855: [GC (Allocation Failure) 201 | [PSYoungGen: 20512K->32K(20992K)], 0.0003355 secs] 202 | 2.879: [GC (Allocation Failure) 203 | [PSYoungGen: 20512K->32K(20992K)], 0.0005592 secs] 204 | 205 | 206 | 207 | 但有时候增加堆内存的大小,并不能解决问题。通过前面学到的知识, 我们可以通过分配分析器找出大部分垃圾产生的位置。实际上在此示例中, 99%的对象属于 `Double` 包装类, 在`readSensor` 方法中创建。最简单的优化, 将创建的 `Double` 对象替换为原生类型 `double`, 而针对 null 值的检测, 可以使用 [Double.NaN](https://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#NaN) 来进行。由于原生类型不算是对象, 也就不会产生垃圾, 导致GC事件。优化之后, 不在堆中分配新对象, 而是直接覆盖一个属性域即可。 208 | 209 | 210 | 对示例程序进行[简单的改造](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/FixedBoxing.java)( [查看diff](https://gist.github.com/gvsmirnov/0270f0f15f9498e3b655) ) 后, GC暂停基本上完全消除。有时候 JVM 也很智能, 会使用 逃逸分析技术(escape analysis technique) 来避免过度分配。简单来说,JIT编译器可以通过分析得知, 方法创建的某些对象永远都不会“逃出”此方法的作用域。这时候就不需要在堆上分配这些对象, 也就不会产生垃圾, 所以JIT编译器的一种优化手段就是: 消除内存分配。请参考 [基准测试](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/jit/EscapeAnalysis.java) 。 211 | 212 | 213 | ## 过早提升(Premature Promotion) 214 | 215 | 216 | **提升速率**(`promotion rate`), 用于衡量单位时间内从年轻代提升到老年代的数据量。一般使用 `MB/sec` 作为单位, 和`分配速率`类似。 217 | 218 | 219 | JVM会将长时间存活的对象从年轻代提升到老年代。根据分代假设, 可能存在一种情况, 老年代中不仅有存活时间长的对象,也可能有存活时间短的对象。这就是过早提升：对象存活时间还不够长的时候就被提升到了老年代。 220 | 221 | 222 | major GC 不是为频繁回收而设计的, 但 major GC 现在也要清理这些生命短暂的对象, 就会导致GC暂停时间过长。这会严重影响系统的吞吐量。 223 | 224 | 225 | ### 如何测量提升速率 226 | 227 | 228 | 可以指定JVM参数 `-XX:+PrintGCDetails -XX:+PrintGCTimeStamps` , 通过GC日志来测量提升速率. JVM记录的GC暂停信息如下所示: 229 | 230 | 231 | 0.291: [GC (Allocation Failure) 232 | [PSYoungGen: 33280K->5088K(38400K)] 233 | 33280K->24360K(125952K), 0.0365286 secs] 234 | [Times: user=0.11 sys=0.02, real=0.04 secs] 235 | 0.446: [GC (Allocation Failure) 236 | [PSYoungGen: 38368K->5120K(71680K)] 237 | 57640K->46240K(159232K), 0.0456796 secs] 238 | [Times: user=0.15 sys=0.02, real=0.04 secs] 239 | 0.829: [GC (Allocation Failure) 240 | [PSYoungGen: 71680K->5120K(71680K)] 241 | 112800K->81912K(159232K), 0.0861795 secs] 242 | [Times: user=0.23 sys=0.03, real=0.09 secs] 243 | 244 | 245 | 246 | 从上面的日志可以得知： GC之前和之后的 年轻代使用量以及堆内存使用量。这样就可以通过差值算出老年代的使用量。GC日志中的信息可以表述为: 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 |
EventTimeYoung decreasedTotal decreasedPromotedPromotion rate
(事件)(耗时)(年轻代减少)(整个堆内存减少)(提升量)(提升速率)
1st GC291ms28,192K8,920K19,272K66.2 MB/sec
2nd GC446ms33,248K11,400K21,848K140.95 MB/sec
3rd GC829ms66,560K30,888K35,672K93.14 MB/sec
Total829ms76,792K92.63 MB/sec
303 | 304 | 305 | 306 | 根据这些信息, 就可以计算出观测周期内的提升速率。平均提升速率为 `92 MB/秒`, 峰值为 `140.95 MB/秒`。 307 | 308 | 309 | 请注意, **只能根据 minor GC 计算提升速率**。 Full GC 的日志不能用于计算提升速率, 因为 major GC 会清理掉老年代中的一部分对象。 310 | 311 | 312 | ### 提升速率的意义 313 | 314 | 315 | 和分配速率一样, 提升速率也会影响GC暂停的频率。但分配速率主要影响 [minor GC](http://blog.csdn.net/renfufei/article/details/54144385#t8), 而提升速率则影响 [major GC](http://blog.csdn.net/renfufei/article/details/54144385#t8) 的频率。有大量的对象提升,自然很快将老年代填满。 老年代填充的越快, 则 major GC 事件的频率就会越高。 316 | 317 | 318 | ![](07_01_how-java-garbage-collection-works.png) 319 | 320 | 321 | 此前说过, full GC 通常需要更多的时间, 因为需要处理更多的对象, 还要执行碎片整理等额外的复杂过程。 322 | 323 | 324 | ### 示例 325 | 326 | 327 | 让我们看一个[过早提升的示例](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/PrematurePromotion.java)。 这个程序创建/获取大量的对象/数据,并暂存到集合之中, 达到一定数量后进行批处理: 328 | 329 | 330 | public class PrematurePromotion { 331 | 332 | private static final Collection accumulatedChunks 333 | = new ArrayList<>(); 334 | 335 | private static void onNewChunk(byte[] bytes) { 336 | accumulatedChunks.add(bytes); 337 | 338 | if(accumulatedChunks.size() > MAX_CHUNKS) { 339 | processBatch(accumulatedChunks); 340 | accumulatedChunks.clear(); 341 | } 342 | } 343 | } 344 | 345 | 346 | 此 [Demo 程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/PrematurePromotion.java) 受到过早提升的影响。下文将进行验证并给出解决办法。 347 | 348 | 349 | ### 过早提升的影响 350 | 351 | 352 | 一般来说,过早提升的症状表现为以下形式: 353 | 354 | 355 | - 短时间内频繁地执行 full GC。 356 | - 每次 full GC 后老年代的使用率都很低, 在10-20%或以下。 357 | - 提升速率接近于分配速率。 358 | 359 | 360 | 要演示这种情况稍微有点麻烦, 所以我们使用特殊手段, 让对象提升到老年代的年龄比默认情况小很多。指定GC参数 `-Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1`, 运行程序之后,可以看到下面的GC日志: 361 | 362 | 363 | 2.176: [Full GC (Ergonomics) 364 | [PSYoungGen: 9216K->0K(10752K)] 365 | [ParOldGen: 10020K->9042K(12288K)] 366 | 19236K->9042K(23040K), 0.0036840 secs] 367 | 2.394: [Full GC (Ergonomics) 368 | [PSYoungGen: 9216K->0K(10752K)] 369 | [ParOldGen: 9042K->8064K(12288K)] 370 | 18258K->8064K(23040K), 0.0032855 secs] 371 | 2.611: [Full GC (Ergonomics) 372 | [PSYoungGen: 9216K->0K(10752K)] 373 | [ParOldGen: 8064K->7085K(12288K)] 374 | 17280K->7085K(23040K), 0.0031675 secs] 375 | 2.817: [Full GC (Ergonomics) 376 | [PSYoungGen: 9216K->0K(10752K)] 377 | [ParOldGen: 7085K->6107K(12288K)] 378 | 16301K->6107K(23040K), 0.0030652 secs] 379 | 380 | 381 | 382 | 乍一看似乎不是过早提升的问题。事实上,在每次GC之后老年代的使用率似乎在减少。但反过来想, 要是没有对象提升或者提升率很小, 也就不会看到这么多的 Full GC 了。 383 | 384 | 385 | 简单解释一下这里的GC行为: 有很多对象提升到老年代, 同时老年代中也有很多对象被回收了, 这就造成了老年代使用量减少的假象. 但事实是大量的对象不断地被提升到老年代, 并触发 full GC。 386 | 387 | 388 | ### 解决方案 389 | 390 | 391 | 简单来说, 要解决这类问题, 需要让年轻代存放得下暂存的数据。有两种简单的方法: 392 | 393 | 一是增加年轻代的大小, 设置JVM启动参数, 类似这样: ` -Xmx64m -XX:NewSize=32m`, 程序在执行时, Full GC 的次数自然会减少很多, 只会对 minor GC的持续时间产生影响: 394 | 395 | 396 | 397 | 2.251: [GC (Allocation Failure) 398 | [PSYoungGen: 28672K->3872K(28672K)] 399 | 37126K->12358K(61440K), 0.0008543 secs] 400 | 2.776: [GC (Allocation Failure) 401 | [PSYoungGen: 28448K->4096K(28672K)] 402 | 36934K->16974K(61440K), 0.0033022 secs] 403 | 404 | 405 | 406 | 二是减少每次批处理的数量, 也能得到类似的结果. 至于选用哪个方案, 要根据业务需求决定。在某些情况下, 业务逻辑不允许减少批处理的数量, 那就只能增加堆内存,或者重新指定年轻代的大小。 407 | 408 | 如果都不可行, 就只能优化数据结构, 减少内存消耗。但总体目标依然是一致的: 让临时数据能够在年轻代存放得下。 409 | 410 | 411 | 412 | 413 | ## Weak, Soft 及 Phantom 引用 414 | 415 | 416 | 另一类影响GC的问题是程序中的 `non-strong 引用`。虽然这类引用在很多情况下可以避免出现 [`OutOfMemoryError`](https://plumbr.eu/outofmemory), 但过量使用也会对GC造成严重的影响, 反而降低系统性能。 417 | 418 | 419 | ## 弱引用的缺点 420 | 421 | 422 | 首先, `弱引用`(`weak reference`) 是可以被GC强制回收的。当垃圾收集器发现一个弱可达对象(`weakly reachable`,即指向该对象的引用只剩下弱引用) 时, 就会将其置入相应的`ReferenceQueue` 中, 变成可终结的对象. 之后可能会遍历这个 reference queue, 并执行相应的清理。典型的示例是清除缓存中不再引用的KEY。 423 | 424 | 425 | 当然, 在这个时候, 我们还可以将该对象赋值给新的强引用, 在最后终结和回收前, GC会再次确认该对象是否可以安全回收。因此, 弱引用对象的回收过程是横跨多个GC周期的。 426 | 427 | 428 | 实际上弱引用使用的很多。大部分缓存框架(**caching solution**)都是基于弱引用实现的, 所以虽然业务代码中没有直接使用弱引用, 但程序中依然会大量存在。 429 | 430 | 431 | 其次, `软引用`(soft reference) 比弱引用更难被垃圾收集器回收. 回收软引用没有确切的时间点, 由JVM自己决定. 一般只会在即将耗尽可用内存时, 才会回收软引用,以作最后手段。这意味着, 可能会有更频繁的 full GC, 暂停时间也比预期更长, 因为老年代中的存活对象会很多。 432 | 433 | 434 | 最后, 使用`虚引用`(phantom reference)时, 必须手动进行内存管理, 以标识这些对象是否可以安全地回收。表面上看起来很正常, 但实际上并不是这样。 javadoc 中写道: 435 | 436 | 437 | > In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null. 438 | 439 | > 为了防止可回收对象的残留, 虚引用对象不应该被获取: `phantom reference` 的 `get` 方法返回值永远是 `null`。 440 | 441 | 442 | 令人惊讶的是, 很多开发者忽略了下一段内容(**这才是重点**): 443 | 444 | 445 | > Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable. 446 | 447 | > 与软引用和弱引用不同, 虚引用不会被 GC 自动清除, 因为他们被存放到队列中. 通过虚引用可达的对象会继续留在内存中, 直到调用此引用的 clear 方法, 或者引用自身变为不可达。 448 | 449 | 450 | 也就是说,我们必须手动调用 [clear()](http://docs.oracle.com/javase/7/docs/api/java/lang/ref/Reference.html#clear()) 来清除虚引用, 否则可能会造成 [OutOfMemoryError](https://plumbr.eu/outofmemory) 而导致 JVM 挂掉. 使用虚引用的理由是, 对于用编程手段来跟踪某个对象何时变为不可达对象, 这是唯一的常规手段。 和软引用/弱引用不同的是, 我们不能复活虚可达(phantom-reachable)对象。 451 | 452 | 453 | ## 示例 454 | 455 | 456 | 让我们看[一个弱引用示例](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/WeakReferences.java), 其中创建了大量的对象, 并在 minor GC 中完成回收。和前面一样, 修改提升阀值。使用的JVM参数为: ` -Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1` , GC日志如下所示: 457 | 458 | 459 | 2.330: [GC (Allocation Failure) 20933K->8229K(22528K), 0.0033848 secs] 460 | 2.335: [GC (Allocation Failure) 20517K->7813K(22528K), 0.0022426 secs] 461 | 2.339: [GC (Allocation Failure) 20101K->7429K(22528K), 0.0010920 secs] 462 | 2.341: [GC (Allocation Failure) 19717K->9157K(22528K), 0.0056285 secs] 463 | 2.348: [GC (Allocation Failure) 21445K->8997K(22528K), 0.0041313 secs] 464 | 2.354: [GC (Allocation Failure) 21285K->8581K(22528K), 0.0033737 secs] 465 | 2.359: [GC (Allocation Failure) 20869K->8197K(22528K), 0.0023407 secs] 466 | 2.362: [GC (Allocation Failure) 20485K->7845K(22528K), 0.0011553 secs] 467 | 2.365: [GC (Allocation Failure) 20133K->9501K(22528K), 0.0060705 secs] 468 | 2.371: [Full GC (Ergonomics) 9501K->2987K(22528K), 0.0171452 secs] 469 | 470 | 471 | 472 | 可以看到, Full GC 的次数很少。但如果使用弱引用来指向创建的对象, 使用JVM参数 `-Dweak.refs=true`, 则情况会发生明显变化. 使用弱引用的原因很多, 比如在 weak hash map 中将对象作为Key的情况。在任何情况下, 使用弱引用都可能会导致以下情形: 473 | 474 | 475 | 2.059: [Full GC (Ergonomics) 20365K->19611K(22528K), 0.0654090 secs] 476 | 2.125: [Full GC (Ergonomics) 20365K->19711K(22528K), 0.0707499 secs] 477 | 2.196: [Full GC (Ergonomics) 20365K->19798K(22528K), 0.0717052 secs] 478 | 2.268: [Full GC (Ergonomics) 20365K->19873K(22528K), 0.0686290 secs] 479 | 2.337: [Full GC (Ergonomics) 20365K->19939K(22528K), 0.0702009 secs] 480 | 2.407: [Full GC (Ergonomics) 20365K->19995K(22528K), 0.0694095 secs] 481 | 482 | 483 | 484 | 可以看到, 发生了多次 full GC, 比起前一节的示例, GC时间增加了一个数量级! 这是过早提升的另一个例子, 但这次情况更加棘手. 当然,问题的根源在于弱引用。这些临死的对象, 在添加弱引用之后, 被提升到了老年代。 但是, 他们现在陷入另一次GC循环之中, 所以需要对其做一些适当的清理。像之前一样, 最简单的办法是增加年轻代的大小, 例如指定JVM参数: `-Xmx64m -XX:NewSize=32m`: 485 | 486 | 487 | 2.328: [GC (Allocation Failure) 38940K->13596K(61440K), 0.0012818 secs] 488 | 2.332: [GC (Allocation Failure) 38172K->14812K(61440K), 0.0060333 secs] 489 | 2.341: [GC (Allocation Failure) 39388K->13948K(61440K), 0.0029427 secs] 490 | 2.347: [GC (Allocation Failure) 38524K->15228K(61440K), 0.0101199 secs] 491 | 2.361: [GC (Allocation Failure) 39804K->14428K(61440K), 0.0040940 secs] 492 | 2.368: [GC (Allocation Failure) 39004K->13532K(61440K), 0.0012451 secs] 493 | 494 | 495 | 496 | 这时候, 对象在 minor GC 中就被回收了。 497 | 498 | 499 | 更坏的情况是使用软引用,例如这个[软引用示例程序](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/SoftReferences.java)。如果程序不是即将发生 `OutOfMemoryError` , 软引用对象就不会被回收. 在示例程序中,用软引用替代弱引用, 立即出现了更多的 Full GC 事件: 500 | 501 | 502 | 2.162: [Full GC (Ergonomics) 31561K->12865K(61440K), 0.0181392 secs] 503 | 2.184: [GC (Allocation Failure) 37441K->17585K(61440K), 0.0024479 secs] 504 | 2.189: [GC (Allocation Failure) 42161K->27033K(61440K), 0.0061485 secs] 505 | 2.195: [Full GC (Ergonomics) 27033K->14385K(61440K), 0.0228773 secs] 506 | 2.221: [GC (Allocation Failure) 38961K->20633K(61440K), 0.0030729 secs] 507 | 2.227: [GC (Allocation Failure) 45209K->31609K(61440K), 0.0069772 secs] 508 | 2.234: [Full GC (Ergonomics) 31609K->15905K(61440K), 0.0257689 secs] 509 | 510 | 511 | 512 | 最有趣的是[虚引用示例](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/PhantomReferences.java)中的虚引用, 使用同样的JVM参数启动, 其结果和弱引用示例非常相似。实际上, full GC 暂停的次数会小得多, 原因前面说过, 他们有不同的终结方式。 513 | 514 | 515 | 如果禁用虚引用清理, 增加JVM启动参数 (`-Dno.ref.clearing=true`), 则可以看到: 516 | 517 | 518 | 4.180: [Full GC (Ergonomics) 57343K->57087K(61440K), 0.0879851 secs] 519 | 4.269: [Full GC (Ergonomics) 57089K->57088K(61440K), 0.0973912 secs] 520 | 4.366: [Full GC (Ergonomics) 57091K->57089K(61440K), 0.0948099 secs] 521 | 522 | 523 | 524 | main 线程中抛出异常 ` java.lang.OutOfMemoryError: Java heap space`. 525 | 526 | 527 | 使用虚引用时要小心谨慎, 并及时清理虚可达对象。如果不清理, 很可能会发生 [`OutOfMemoryError`](https://plumbr.eu/outofmemory). 请相信我们的经验教训: 处理 reference queue 的线程中如果没 catch 住 exception , 系统很快就会被整挂了。 528 | 529 | 530 | ### 使用非强引用的影响 531 | 532 | 533 | 建议使用JVM参数 `-XX:+PrintReferenceGC` 来看看各种引用对GC的影响. 如果将此参数用于启动 [弱引用示例](https://github.com/gvsmirnov/java-perv/blob/master/labs-8/src/main/java/ru/gvsmirnov/perv/labs/gc/WeakReferences.java) , 将会看到: 534 | 535 | 536 | 2.173: [Full GC (Ergonomics) 537 | 2.234: [SoftReference, 0 refs, 0.0000151 secs] 538 | 2.234: [WeakReference, 2648 refs, 0.0001714 secs] 539 | 2.234: [FinalReference, 1 refs, 0.0000037 secs] 540 | 2.234: [PhantomReference, 0 refs, 0 refs, 0.0000039 secs] 541 | 2.234: [JNI Weak Reference, 0.0000027 secs] 542 | [PSYoungGen: 9216K->8676K(10752K)] 543 | [ParOldGen: 12115K->12115K(12288K)] 544 | 21331K->20792K(23040K), 545 | [Metaspace: 3725K->3725K(1056768K)], 546 | 0.0766685 secs] 547 | [Times: user=0.49 sys=0.01, real=0.08 secs] 548 | 2.250: [Full GC (Ergonomics) 549 | 2.307: [SoftReference, 0 refs, 0.0000173 secs] 550 | 2.307: [WeakReference, 2298 refs, 0.0001535 secs] 551 | 2.307: [FinalReference, 3 refs, 0.0000043 secs] 552 | 2.307: [PhantomReference, 0 refs, 0 refs, 0.0000042 secs] 553 | 2.307: [JNI Weak Reference, 0.0000029 secs] 554 | [PSYoungGen: 9215K->8747K(10752K)] 555 | [ParOldGen: 12115K->12115K(12288K)] 556 | 21331K->20863K(23040K), 557 | [Metaspace: 3725K->3725K(1056768K)], 558 | 0.0734832 secs] 559 | [Times: user=0.52 sys=0.01, real=0.07 secs] 560 | 2.323: [Full GC (Ergonomics) 561 | 2.383: [SoftReference, 0 refs, 0.0000161 secs] 562 | 2.383: [WeakReference, 1981 refs, 0.0001292 secs] 563 | 2.383: [FinalReference, 16 refs, 0.0000049 secs] 564 | 2.383: [PhantomReference, 0 refs, 0 refs, 0.0000040 secs] 565 | 2.383: [JNI Weak Reference, 0.0000027 secs] 566 | [PSYoungGen: 9216K->8809K(10752K)] 567 | [ParOldGen: 12115K->12115K(12288K)] 568 | 21331K->20925K(23040K), 569 | [Metaspace: 3725K->3725K(1056768K)], 570 | 0.0738414 secs] 571 | [Times: user=0.52 sys=0.01, real=0.08 secs] 572 | 573 | 574 | 575 | 只有确定 GC 对应用的吞吐量和延迟造成影响之后, 才应该花心思来分析这些信息, 审查这部分日志。通常情况下, 每次GC清理的引用数量都是很少的, 大部分情况下为 `0`。如果GC 花了较多时间来清理这类引用, 或者清除了很多的此类引用, 就需要进一步观察和分析了。 576 | 577 | 578 | ### 解决方案 579 | 580 | 581 | 如果程序确实碰到了 `mis-`, `ab-` 问题或者滥用 weak, soft, phantom 引用, 一般都要修改程序的实现逻辑。每个系统不一样, 因此很难提供通用的指导建议, 但有一些常用的办法: 582 | 583 | 584 | - `弱引用`(`Weak references`) —— 如果某个内存池的使用量增大, 造成了性能问题, 那么增加这个内存池的大小(可能也要增加堆内存的最大容量)。如同示例中所看到的, 增加堆内存的大小, 以及年轻代的大小, 可以减轻症状。 585 | - `虚引用`(`Phantom references`) —— 请确保在程序中调用了虚引用的 `clear` 方法。编程中很容易忽略某些虚引用, 或者清理的速度跟不上生产的速度, 又或者清除引用队列的线程挂了, 就会对GC 造成很大压力, 最终可能引起 [`OutOfMemoryError`](http://www.oracle.com/technetwork/articles/javaee/index-jsp-136424.html)。 586 | - `软引用`(`Soft references`) —— 如果确定问题的根源是软引用, 唯一的解决办法是修改程序源码, 改变内部实现逻辑。 587 | 588 | 589 | ## 其他示例 590 | 591 | 592 | 前面介绍了最常见的GC性能问题。但我们学到的很多原理都没有具体的场景来展现。本节介绍一些不常发生, 但也可能会碰到的问题。 593 | 594 | 595 | ### RMI 与 GC 596 | 597 | 598 | 如果系统提供或者消费 [RMI](http://www.oracle.com/technetwork/articles/javaee/index-jsp-136424.html) 服务, 则JVM会定期执行 full GC 来确保本地未使用的对象在另一端也不占用空间. 记住, 即使你的代码中没有发布 RMI 服务, 但第三方或者工具库也可能会打开 RMI 终端. 最常见的元凶是 JMX, 如果通过JMX连接到远端, 底层则会使用 RMI 发布数据。 599 | 600 | 601 | 问题是有很多不必要的周期性 full GC。查看老年代的使用情况, 一般是没有内存压力, 其中还存在大量的空闲区域, 但 full GC 就是被触发了, 也就会暂停所有的应用线程。 602 | 603 | 604 | 这种周期性调用 `System.gc()` 删除远程引用的行为, 是在 `sun.rmi.transport.ObjectTable` 类中, 通过 `sun.misc.GC.requestLatency(long gcInterval)` 调用的。 605 | 606 | 607 | 对许多应用来说, 根本没必要, 甚至对性能有害。 禁止这种周期性的 GC 行为, 可以使用以下 JVM 参数: 608 | 609 | 610 | java -Dsun.rmi.dgc.server.gcInterval=9223372036854775807L 611 | -Dsun.rmi.dgc.client.gcInterval=9223372036854775807L 612 | com.yourcompany.YourApplication 613 | 614 | 615 | 616 | 这让 `Long.MAX_VALUE` 毫秒之后, 才调用 [`System.gc()`](http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#gc()), 实际运行的系统可能永远都不会触发。 617 | 618 | > ObjectTable.class 619 | 620 | private static final long gcInterval = 621 | ((Long)AccessController.doPrivileged( 622 | new GetLongAction("sun.rmi.dgc.server.gcInterval", 3600000L) 623 | )).longValue(); 624 | 625 | 626 | 可以看到, 默认值为 `3600000L`,也就是1小时触发一次 Full GC。 627 | 628 | 629 | 另一种方式是指定JVM参数 `-XX:+DisableExplicitGC`, 禁止显式地调用 `System.gc()`. 但我们**强烈反对** 这种方式, 因为埋有地雷。 630 | 631 | 632 | ### JVMTI tagging 与 GC 633 | 634 | 635 | 如果在程序启动时指定了 Java Agent (`-javaagent`), agent 就可以使用 [JVMTI tagging](http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#Heap) 标记堆中的对象。agent 使用tagging的种种原因本手册不详细讲解, 但如果 tagging 标记了大量的对象, 很可能会引起 GC 性能问题, 导致延迟增加, 以及吞吐量降低。 636 | 637 | 638 | 问题发生在 native 代码中, `JvmtiTagMap::do_weak_oops` 在每次GC时, 都会遍历所有标签(tag),并执行一些比较耗时的操作。更坑的是, 这种操作是串行执行的。 639 | 640 | 641 | 如果存在大量的标签, 就意味着 GC 时有很大一部分工作是单线程执行的, GC暂停时间可能会增加一个数量级。 642 | 643 | 644 | 检查是否因为 agent 增加了GC暂停时间, 可以使用诊断参数 `–XX:+TraceJVMTIObjectTagging`. 启用跟踪之后, 可以估算出内存中 tag 映射了多少 native 内存, 以及遍历所消耗的时间。 645 | 646 | 647 | 如果你不是 agent 的作者, 那一般是搞不定这类问题的。除了提BUG之外你什么都做不了. 如果发生了这种情况, 请建议厂商清理不必要的标签。 648 | 649 | 650 | ### 巨无霸对象的分配(Humongous Allocations) 651 | 652 | 653 | 如果使用 G1 垃圾收集算法, 会产生一种巨无霸对象引起的 GC 性能问题。 654 | 655 | > **说明**: 在G1中, 巨无霸对象是指所占空间超过一个小堆区(region) `50%` 的对象。 656 | 657 | 658 | 频繁的创建巨无霸对象, 无疑会造成GC的性能问题, 看看G1的处理方式: 659 | 660 | 661 | - 如果某个 region 中含有巨无霸对象, 则巨无霸对象后面的空间将不会被分配。如果所有巨无霸对象都超过某个比例, 则未使用的空间就会引发内存碎片问题。 662 | - G1 没有对巨无霸对象进行优化。这在 JDK 8 以前是个特别棘手的问题 —— 在 [**Java 1.8u40**](https://bugs.openjdk.java.net/browse/JDK-8027959) 之前的版本中, 巨无霸对象所在 region 的回收只能在 full GC 中进行。最新版本的 Hotspot JVM, 在 marking 阶段之后的 cleanup 阶段中释放巨无霸区间, 所以这个问题在新版本JVM中的影响已大大降低。 663 | 664 | 665 | 要监控是否存在巨无霸对象, 可以打开GC日志, 使用的命令如下: 666 | 667 | 668 | java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 669 | -XX:+PrintReferenceGC -XX:+UseG1GC 670 | -XX:+PrintAdaptiveSizePolicy -Xmx128m 671 | MyClass 672 | 673 | 674 | GC 日志中可能会发现这样的部分: 675 | 676 | 677 | 0.106: [G1Ergonomics (Concurrent Cycles) 678 | request concurrent cycle initiation, 679 | reason: occupancy higher than threshold, 680 | occupancy: 60817408 bytes, 681 | allocation request: 1048592 bytes, 682 | threshold: 60397965 bytes (45.00 %), 683 | source: concurrent humongous allocation] 684 | 0.106: [G1Ergonomics (Concurrent Cycles) 685 | request concurrent cycle initiation, 686 | reason: requested by GC cause, 687 | GC cause: G1 Humongous Allocation] 688 | 0.106: [G1Ergonomics (Concurrent Cycles) 689 | initiate concurrent cycle, 690 | reason: concurrent cycle initiation requested] 691 | 0.106: [GC pause (G1 Humongous Allocation) 692 | (young) (initial-mark) 693 | 0.106: [G1Ergonomics (CSet Construction) 694 | start choosing CSet, 695 | _pending_cards: 0, 696 | predicted base 697 | time: 10.00 ms, 698 | remaining time: 190.00 ms, 699 | target pause time: 200.00 ms] 700 | 701 | 702 | 703 | 这样的日志就是证据, 表明程序中确实创建了巨无霸对象. 可以看到: `G1 Humongous Allocation ` 是 GC暂停的原因。 再看前面一点的 `allocation request: 1048592 bytes` , 可以发现程序试图分配一个 `1,048,592` 字节的对象, 这要比巨无霸区域(`2MB`)的 `50%` 多出 16 个字节。 704 | 705 | 706 | 707 | 第一种解决方式, 是修改 region size , 以使得大多数的对象不超过 `50%`, 也就不进行巨无霸对象区域的分配。 region 的默认大小在启动时根据堆内存的大小算出。但也可以指定参数来覆盖默认设置, `-XX:G1HeapRegionSize=XX`。 指定的 region size 必须在 `1~32MB` 之间, 还必须是2的幂 【2^10 = 1024 = 1KB; 2^20=1MB; 所以 region size 只能是: `1m`,`2m`,`4m`,`8m`,`16m`,`32m`】。 708 | 709 | 710 | 这种方式也有副作用, 增加 region 的大小也就变相地减少了 region 的数量, 所以需要谨慎使用, 最好进行一些测试, 看看是否改善了吞吐量和延迟。 711 | 712 | 713 | 更好的方式需要一些工作量, 如果可以的话, 在程序中限制对象的大小。最好是使用分析器, 展示出巨无霸对象的信息, 以及分配时所在的堆栈跟踪信息。 714 | 715 | 716 | ### 总结 717 | 718 | 719 | JVM上运行的程序多种多样, 启动参数也有上百个, 其中有很多会影响到 GC, 所以调优GC性能的方法也有很多种。 720 | 721 | 722 | 还是那句话, 没有真正的银弹, 能满足所有的性能调优指标。 我们能做的只是介绍一些常见的/和不常见的示例, 让你在碰到类似问题时知道是怎么回事。深入理解GC的工作原理, 熟练应用各种工具, 就可以进行GC调优, 提高程序性能。 723 | 724 | 725 | 原文链接: [GC Tuning: In Practice](https://plumbr.eu/handbook/gc-tuning-in-practice) 726 | 727 | -------------------------------------------------------------------------------- /Java_GC_Hanbook_CN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/Java_GC_Hanbook_CN.pdf -------------------------------------------------------------------------------- /Plumbr_Handbook_Java_Garbage_Collection.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncounter/gc-handbook/0d4b04c67aee2bbfe7650ee7591b0d477129afb4/Plumbr_Handbook_Java_Garbage_Collection.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Java垃圾收集必备手册 2 | == 3 | 4 | 5 | > Github项目地址: [https://github.com/cncounter/gc-handbook](https://github.com/cncounter/gc-handbook) 6 | > 7 | > 时间: 2017年3月15日 8 | > 9 | > 版本: V0.2 10 | > 11 | > 状态: 第2次校对 12 | 13 | 14 | 15 | ## 目录 16 | 17 | [1. 垃圾回收简介](01_What_Is_Garbage_Collection_CN.md) 18 | 19 | [2. Java的垃圾收集](02_Garbage_Collection_in_Java_CN.md) 20 | 21 | [3. GC 算法(基础篇)](03_GC_Algorithms_Basics_CN.md) 22 | 23 | [4. GC 算法(实现篇)](04_GC_Algorithms_Implementations_CN.md) 24 | 25 | [5. GC 调优(基础篇)](05_GC_Tuning_Basics_CN.md) 26 | 27 | [6. GC 调优(工具篇)](06_GC_Tuning_Tooling_CN.md) 28 | 29 | [7. GC 调优(实战篇)](07_GC_Tuning_In_Practice_CN.md) 30 | 31 | 32 | ## 下载 33 | 34 | 35 | Java垃圾收集必备手册_中文版.pdf 36 | 37 | 38 | 39 | 40 | ## 相关链接 41 | 42 | 翻译人员: [铁锚 http://blog.csdn.net/renfufei](http://blog.csdn.net/renfufei) 43 | 44 | 加入【[CNC开源技术交流群: 316630025](http://jq.qq.com/?_wv=1027&k=2FzyKg3)】 45 | 46 | 47 | --------------------------------------------------------------------------------