关于垃圾收集的一些话
“很难相信Java居然能和C++一样快，甚至还能更快一些。”
据我本身的实践，这种说法确实创立。然而，我也发明很多关于速度的猜疑都来自一些早期的实现方法。由于这些方法并非出格有效，所以没有一个模子可供参考，不能表明Java速度快的原因。
我之所以想到速度，部门原因是由于C++模子。C++将本身的主要精神放在编译期间“静态”产生的所有工作上，所以措施的运行期版本很是短小和快速。C++也直接成立在C模子的基本上（主要为了向后兼容），但有时仅仅由于它在C中能按特定的方法事情，所以也是C++中最利便的一种要领。最重要的一种环境是C和C++对内存的打点方法，它是某些人以为Java速度必定慢的重要依据：在Java中，所有工具都必需在内存“堆”里建设。
而在C++中，工具是在仓库中建设的。这样可到达更快的速度，因为当我们进入一个特定的浸染域时，仓库指针会向下移动一个单元，为谁人浸染域内建设的、以仓库为基本的所有工具分派存储空间。而当我们分开浸染域的时候（挪用完毕所有局部构建器后），仓库指针会向上移动一个单元。然而，在C++里建设“内存堆”（Heap）工具凡是会慢得多，因为它成立在C的内存堆基本上。这种内存堆实际是一个大的内存池，要求必需举办再轮回（再生）。在C++里挪用delete今后，释放的内存会在堆里留下一个洞，所以再挪用new的时候，存储分派机制必需举办某种形式的搜索，使工具的存储与堆内任何现成的洞相配，不然就会很快用光堆的存储空间。之所以内存堆的分派会在C++里对机能造成如此重大的机能影响，对可用内存的搜索正是一个重要的原因。所以建设基于仓库的工具要快得多。
同样地，由于C++如此多的事情都在编译期间举办，所以必需思量这方面的因素。但在Java的某些处所，工作的产生却要显得“动态”得多，它会改变模子。建设工具的时候，垃圾收集器的利用对付提高工具建设的速度发生了显著的影响。从外貌上看，这种说法好像有些奇怪——存储空间的释放会对存储空间的分派造成影响，但它正是JVM采纳的重要手段之一，这意味着在Java中为堆工具分派存储空间险些能到达与C++中在仓库里建设存储空间一样快的速度。
可将C++的堆（以及更慢的Java堆）想象成一个庭院，每个工具都拥有本身的一块地盘。在今后的某个时间，这种“不动产”会被丢弃，并且必需再生。但在某些JVM里，Java堆的事情方法却是颇有差异的。它更象一条传送带：每次分派了一个新工具后，城市朝前移动。这意味着工具存储空间的分派可以到达很是快的速度。“堆指针”简朴地向前移至童贞地，所以它与C++的仓库分派方法险些是完全沟通的（虽然，在数据记录上会多花一些开销，但要比搜索存储空间快多了）。
此刻，各人大概留意到了堆事实并非一条传送带。如按那种方法看待它，最终就要求举办大量的页互换（这对机能的发挥会发生庞大滋扰），这样终究会用光内存，呈现内存分页错误。所以这儿必需采纳一个能力，那就是著名的“垃圾收集器”。它在收集“垃圾”的同时，也认真压缩堆里的所有工具，将“堆指针”移至尽大概接近传送带开头的处所，远离产生（内存）分页错误的所在。垃圾收集器会从头布置所有对象，使其成为一个高速、无限自由的堆模子，同时游刃有余地分派存储空间。
为真正把握它的事情道理，我们首先需要领略差异垃圾收集器（GC）采纳的事情方案。一种简朴、但速度较慢的GC技能是引用计数。这意味着每个工具都包括了一个引用计数器。每当一个句柄同一个工具毗连起来时，引用计数器就会增值。每当一个句柄超出本身的浸染域，可能设为null时，引用计数就会减值。这样一来，只要措施处于运行状态，就需要持续举办引用计数打点——尽量这种打点自己的开销较量少。垃圾收集器会在整个工具列表中移动巡视，一旦它发明个中一个引用计数成为0，就释放它占据的存储空间。但这样做也有一个缺点：若工具彼此之间举办轮回引用，那么纵然引用计数不是0，仍有大概属于应收掉的“垃圾”。为了找出这种自引用的组，要求垃圾收集器举办大量特另外事情。引用计数属于垃圾收集的一种范例，但它看起来并不适合在所有JVM方案中回收。
在速度更快的方案里，垃圾收集并不成立在引用计数的基本上。相反，它们基于这样一个道理：所有非死锁的工具最终都必定能回溯至一个句柄，该句柄要么存在于仓库中，要么存在于静态存储空间。这个回溯链大概经验了几层工具。所以，假如从仓库和静态存储区域开始，并经验所有句柄，就能找出所有勾当的工具。对付本身找到的每个句柄，都必需跟踪到它指向的谁人工具，然后跟从谁人工具中的所有句柄，“跟踪追击”到它们指向的工具……等等，直到遍历了从仓库或静态存储区域中的句柄提倡的整个链接网路为止。半途移经的每个工具都必需仍处于勾当状态。留意对付那些非凡的自引用组，并不会呈现前述的问题。由于它们基础找不到，所以会自动看成垃圾处理惩罚。
#p#分页标题#e#
在这里叙述的要领中，JVM回收一种“自适应”的垃圾收集方案。对付它找到的那些勾当工具，详细采纳的操纵取决于当前正在利用的是什么变体。个中一个变体是“遏制和复制”。这意味着由于一些不久之后就会很是明明的原因，措施首先会遏制运行（并非一种靠山收集方案）。随后，已找到的每个勾当工具城市从一个内存堆复制到另一个，留下所有的垃圾。除此以外，跟着工具复制到新堆，它们会一个接一个地聚焦在一起。这样可使新堆显得越发紧凑（并使新的存储区域可以简朴地抽离末端，就象前面报告的那样）。
虽然，将一个工具从一处挪到另一处时，指向谁人工具的所有句柄（引用）都必需改变。对付那些通过跟踪内存堆的工具而得到的句柄，以及那些静态存储区域，都可以当即改变。但在“遍历”进程中，尚有大概碰着指向这个工具的其他句柄。一旦发明这个问题，就连忙举办批改（可想象一个散列表将老地点映射成新地点）。
有两方面的问题使复制收集器显得效率低下。第一个问题是我们拥有两个堆，所有内存都在这两个独立的堆内往返移动，要求支付的打点量是实际需要的两倍。为办理这个问题，有些JVM按照需要分派内存堆，并将一个堆简朴地复制到另一个。
第二个问题是复制。跟着措施变得越来越“结实”，它险些不发生或发生很少的垃圾。尽量如此，一个副本收集器仍会将所有内存从一处复制到另一处，这显得很是挥霍。为制止这个问题，有些JVM能侦测是否没有发生新的垃圾，并随即换取另一种方案（这即是“自适应”的缘由）。另一种方案叫作“标志和排除”，Sun公司的JVM一直回收的都是这种方案。对付通例性的应用，标志和排除显得很是慢，但一旦知道本身不发生垃圾，可能只发生很少的垃圾，它的速度就会很是快。
标志和排除回收沟通的逻辑：从仓库和静态存储区域开始，并跟踪所有句柄，寻找勾当工具。然而，每次发明一个勾当工具的时候，就会配置一个标志，为谁人工具作上“暗号”。但此时尚不收集谁人工具。只有在标志进程竣事，排除进程才正式开始。在排除进程中，死锁的工具会被释放然而，不会举办任何形式的复制，所以假使收集器抉择压缩一个断续的内存堆，它通过移动周围的工具来实现。
“遏制和复制”向我们表白这种范例的垃圾收集并不是在靠山举办的；相反，一旦产生垃圾收集，措施就会遏制运行。在Sun公司的文档库中，可发明很多处所都将垃圾收集界说成一种低优先级的靠山历程，但它只是一种理论上的尝试，实际基础不能事情。在实际应用中，Sun的垃圾收集器会在内存淘汰时运行。除此以外，“标志和排除”也要求措施遏制运行。
正如早先指出的那样，在这里先容的JVM中，内存是按大块分派的。若分派一个大块头工具，它会得到本身的内存块。严格的“遏制和复制”要求在释放旧堆之前，将每个勾当的工具从源堆复制到一个新堆，此时会涉及大量的内存转换事情。通过内存块，垃圾收集器凡是可操作死块复制工具，就象它举办收集时那样。每个块都有一个生成计数，用于跟踪它是否依然“存活”。凡是，只有自上次垃圾收集以来建设的块才会获得压缩；对付其他所有块，假如已从其他某些处所举办了引用，那么生成计数城市溢出。这是很多短期的、姑且的工具常常碰着的环境。会周期性地举办一次完整排除事情——大块头的工具仍未复制（只是让它们的生成计数溢出），而那些包括了小工具的块会举办复制和压缩。JVM会监督垃圾收集器的效率，假如由于所有工具都属于恒久工具，造成垃圾收集成为挥霍时间的一个进程，就会切换到“标志和排除”方案。雷同地，JVM会跟踪监督乐成的“标志与排除”事情，若内存堆变得越来越“狼藉”，就会换回“遏制和复制”方案。“自界说”的说法就是从这种行为来的，我们将其最后总结为：“按照环境，自动转换遏制和复制／标志和排除这两种模式”。
#p#分页标题#e#
JVM还回收了其他很多加快方案。个中一个出格重要的涉及装载器以及JIT编译器。若必需装载一个类（凡是是我们首次想建设谁人类的一个工具时），会找到.class文件，并将谁人类的字节码送入内存。此时，一个要领是用JIT编译所有代码，但这样做有两方面的缺点：它会花更多的时间，若与措施的运行时间综合思量，编译时间尚有大概更长；并且它增大了执行文件的长度（字节码比扩展过的JIT代码精简得多），这有大概造成内存页互换，从而显著放慢一个措施的执行速度。另一种替代步伐是：除非确有须要，不然不经JIT编译。这样一来，那些基础不会执行的代码就大概永远得不到JIT的编译。
由于JVM对欣赏器来说是外置的，各人大概但愿在利用欣赏器的时候从一些JVM的速度提高中得到长处。但很是不幸，JVM今朝不能与差异的欣赏器举办相同。为发挥一种特定JVM的潜力，要么利用内建了那种JVM的欣赏器，要么只有运行独立的Java应用措施。
