📄 appendixe.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:Tjava14.rtf
Application Directory:c:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:02/04/2000
Translation Time:23:26:34
Translation Platform:Win32
Number of Output files:27
This File:AppendixE.html
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>E: A bit about garbage collection</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/TIJ2/index.html">2nd Edition</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Training.html">Seminars</a> ]
[ <a href="http://www.mindview.net/javaCD2.html">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 1st edition</FONT></H2>
<H3><FONT FACE="Verdana">©1998 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixD.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="AppendixF.html">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc407441466"></A><A NAME="_Toc408018866"></A><A NAME="Heading652"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
E: A bit about garbage collection</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>It’s hard to
believe that Java could possibly be as fast or faster than
C++<I>.</I></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index3123"></A><FONT FACE="Georgia">This
assertion has yet to be proven to my satisfaction. However, I’ve begun to
see that many of my doubts about
<A NAME="Index3124"></A><A NAME="Index3125"></A><A NAME="Index3126"></A>speed
come from early implementations that were not particularly efficient so there
was no model at which to point to explain how Java could be
fast.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Part of the way I’ve thought
about speed has come from being cloistered with the <A NAME="Index3127"></A>C++
model. C++ is very focused on everything happening statically, at compile time,
so that the run-time image of the program is small and fast. C++ is also based
directly on the C model, primarily for backwards compatibility, but sometimes
simply because it worked a particular way in C so it was the easiest approach in
C++. One of the most important cases is the way memory is managed in C and C++,
and this has to do with one of my more fundamental assertions about why Java
must be slow: in Java, all objects must be created on the heap.
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In C++, creating objects on the
<A NAME="Index3128"></A>stack is fast because when you enter a particular scope
the stack pointer is moved down once to allocate storage for all the stack-based
objects created in that scope, and when you leave the scope (after all the local
destructors have been called) the stack pointer is moved up once. However,
creating heap objects in C++ is typically much slower because it’s based
on the C concept of a heap as a big pool of memory that (and this is essential)
must be recycled. When you call <B>delete</B> in C++ the released memory leaves
a hole in the heap, so when you call <B>new</B>, the storage allocation
mechanism must go seeking to try to fit the storage for your object into any
existing holes in the heap or else you’ll rapidly run out of heap storage.
Searching for available pieces of memory is the reason that allocating heap
storage has such a performance impact in C++, so it’s far faster to create
stack-based objects.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Again, because so much of C++ is
based on doing everything at compile-time, this makes sense. But in Java there
are certain places where things happen more dynamically and it changes the
model. When it comes to creating objects, it turns out that the garbage
collector can have a significant impact on increasing the speed of object
creation. This might sound a bit odd at first – that storage release
affects storage allocation – but it’s the way some JVMs work and it
means that allocating storage for heap objects in Java can be nearly as fast as
creating storage on the stack in C++.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You can think of the C++ heap (and
a slow implementation of a Java heap) as a yard where each object stakes out its
own piece of turf. This real estate can become abandoned sometime later and must
be reused. In some JVMs, the Java heap is quite different; it’s more like
a conveyor belt that moves forward every time you allocate a new object. This
means that object storage allocation is remarkably rapid. The “heap
pointer” is simply moved forward into virgin territory, so it’s
effectively the same as C++’s stack allocation. (Of course, there’s
a little extra overhead for bookkeeping but it’s nothing like searching
for storage.)</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Now you might observe that the heap
isn’t in fact a conveyor belt, and if you treat it that way you’ll
eventually start paging memory a lot (which is a big performance hit) and later
run out. The trick is that the garbage collector steps in and while it collects
the garbage it compacts all the objects in the heap so that you’ve
effectively moved the “heap pointer” closer to the beginning of the
conveyor belt and further away from a page fault. The garbage collector
rearranges things and makes it possible for the high-speed, infinite-free-heap
model to be used while allocating storage.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To understand how this works, you
need to get a little better idea of the way the different garbage collector (GC)
schemes work. A simple but slow GC technique is reference counting. This means
that each object contains a reference counter, and every time a handle is
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -