Java知识分享网 - 轻松学习从此开始!    





Java1234 VIP课程


当前位置: 主页 > Java文档 > Java基础相关 >

Understanding_Java_Garbage_Collection_v4 PDF 下载

时间:2020-04-24 19:27来源: 作者:小锋  
Understanding_Java_Garbage_Collection_v4 PDF 下载
Understanding_Java_Garbage_Collection_v4 PDF 下载


Executive Summary 
Garbage Collection (GC) is an integral part of 
application behavior on Java platforms, yet it is often 
misunderstood. Java developers need to understand 
how GC works and how the actions they can take in 
selecting and tuning collector mechanisms, as well 
as in application architecture choices, can affect 
runtime performance, scalability and reliability. 
This white paper reviews and classifies the various 
garbage collectors and collection techniques available 
in JVMs today. This paper provides an overview of 
common garbage collection techniques, algorithms 
and defines terms and metrics common to all 
collectors including: 
. Generational 
. Parallel 
. Stop-the-world
. Incremental 
. Concurrent
. Mostly-concurrent 
The paper classifies each major JVM collector’s 
mechanisms and characteristics and discusses the 
trade-offs involved in balancing requirements for 
responsiveness, throughput, space, and available 
memory across varying scale levels. The paper con￾cludes with some pitfalls, common misconceptions, 
and “myths” around garbage collection behavior, as 
well as examples of how certain choices can result 
in impressive application behavior.
4 Understanding Java Garbage Collection
The Java programming language utilizes a managed 
runtime (the Java Virtual Machine, or JVM) to improve 
developer productivity and provide cross-platform 
portability. Because different operating systems and 
hardware platforms vary in the ways that they manage 
memory, the JVM performs this function for the 
developer, allocating memory as objects are created 
and freeing it when they are no longer used. This 
process of freeing unused memory is called ‘garbage 
collection’ (GC), and is performed by the JVM on the 
memory heap during application execution. 
Java garbage collection can have a big impact on 
application performance and throughput. As the JVM 
heap size grows, so does the amount of time that an 
application must pause to allow the JVM to perform 
GC. The result can be long, unexpected pauses 
that can delay transactions, deteriorate application 
throughput, cause user-session time-outs, force nodes 
to fall out of clusters, or result in even more severe 
business related losses (e.g. drop in revenue or dam￾age to reputation). 
This paper explains in more detail how garbage 
collection works, the different algorithm types 
employed by commercially available JVMs, and how 
developers and architects can make better informed 
decisions on which garbage collector to use and how 
to maximize application performance.
Why Care About the Java Garbage 
Overall garbage collection is much better and more 
efficient than you might think. It’s much faster than 
malloc() at allocating memory and dead objects cost 
nothing to collect (really!). GC will find all the dead 
objects, even in cyclic graphs, without any assistance 
from the developer. But in many ways garbage collection 
is much more insidious than many developers and 
architects realize. 
For most collectors GC related pauses are propor￾tional to size of their heaps which is approximately 1 
second for each gigabyte of live objects. So, a larger 
heap (which can be advantageous for most apps) 
means a longer pause. Worse yet, if you run a 20 
minute test and tune until all the pauses go away, 
the likelihood is that you’ve simply moved the pause 
to the 21st minute. So unfortunately, the pause will 
still happen and your application will suffer. In 
addition, the presence of garbage collection doesn’t 
eliminate object leaks – the developer still has to 
find and fix references holding those leaked objects. 
The good news is Java does provide some level of 
GC control. Developers and architects can make 
decisions that can adjust application performance, 
due to the behavior of the garbage collector. For 
example, in C++ it makes sense to null every 
reference field when it’s no longer needed. However, 
in a Java program, coding in nullifiers everywhere is 
disastrous and far worse than coding in nothing. If 
every single class uses a finalizer to null reference 
fields, the garbage collector will potentially have to 
perform millions of object finalizations per GC cycle 
– leading to very long garbage collection pauses. 
Trying to solve garbage collection at the application 
programming layer is dangerous. It takes a lot of 
practice and understanding to get it right; time that 
could better spent building value-added features. 
And, even if you make all the right decisions, it is 
likely that other code your application leverages will 
not be optimized or the application workload changes 
over time, and your application will still have GC 
related performance issues. 
Also, depending on the characteristics of your 
application, choosing the wrong garbage collector 
type or using the wrong settings can greatly increase 
pause times or even cause out-of-memory crashes. 
With a proper understand of garbage collection and 
what your available options are, you can make better 
informed decisions and product choices that can 
improve the performance and reliability of your 
application at runtime. 
5 Understanding Java Garbage Collection
Classifying the Collector 
Garbage collectors are divided into several types. 
For each type some collectors are categorized as 
‘mostly’, as in ‘mostly concurrent’. This means that 
sometimes it doesn’t operate according to that 
classification and has a fallback mechanism for 
when that occurs. So, a ‘mostly concurrent’ collector 
may operate concurrently with application execution 
and only occasionally stop-the-world if needed. 
Concurrent collector – performs garbage collection 
concurrently while application execution continues. 
Parallel collector – uses multiple threads. A collector can be concurrent but not parallel, and it can be 
concurrent AND parallel. (Side note – be cautious 
when researching older literature on garbage collection, since what we used to call parallel is now called 
Stop-the-world (STW) – is the opposite of concurrent. 
It performs garbage collection while the application is 
completely stopped. 
Incremental – performs garbage collection as a 
series of smaller increments with potentially long 
gaps in between. The application is stopped during 
garbage collection but runs in between increments.




金信彩票开户 爱投彩票注册 555彩注册 优优彩票网 加拿大28 百胜彩票开户 四季彩票登陆 聚发彩票投注 大通彩票注册 优优彩票官网