| 失效链接处理 |
|
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 concludes 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
Introduction
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 damage 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
Collector?
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 proportional 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
concurrent.)
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.
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
