关于垃圾堆积的一些话[Java编程]

“很难相信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筹划中采取.

在速度更快的筹划里,垃圾汇集并不成立在引用计数的底子上.相反,它们基于这样一个原理:全部非死锁的对象终究都必定能回溯至一个句柄,该句柄要末存在于仓库中,要末存在于静态存储空间.这个回溯链大概阅历了几层对象.所以,假如从仓库和静态存储区域开始,并阅历全部句柄,就可以找出全部活动的对象.关于自己找到的每个句柄,都必须跟踪到它指向的那个对象,然后跟随那个对象中的全部句柄,“跟踪追击”到它们指向的对象……等等,直到遍历了从仓库或静态存储区域中的句柄发动的整个链接网路为止.半途移经的每个对象都必须仍处于活动状况.注意关于那些特别的自引用组,并不会呈现前述的问题.由于它们根本找不到,所以会自动当作垃圾处理.

在这里阐述的办法中,JVM采取一种“自适应”的垃圾汇集筹划.关于它找到的那些活动对象,具体采纳的操作取决于当前正在利用的是什么变体.此中一个变体是“终止和复制”.这意味着由于一些不久之后就会十清楚显的缘由,程序首先会终止运行（并非一种后台汇集筹划）.随后,已找到的每个活动对象城市从一个内存堆复制到另一个,留下全部的垃圾.除此以外,随着对象复制到新堆,它们会一个接一个地聚焦在一同.这样可以使新堆显得愈抓紧凑（并使新的存储区域可以简单地抽离末尾,就象前面报告的那样）.

当然,将一个对象从一处挪到另一处时,指向那个对象的全部句柄（引用）都必须改变.关于那些通过跟踪内存堆的对象而得到的句柄,以及那些静态存储区域,都可以当即改变.但在“遍历”历程中,还有大概碰到指向这个对象的其他句柄.一旦发现这个问题,就当即举行改正（可想象一个散列表将老地址映射成新地址）.

有两方面的问题使复制汇集器显得效率低下.第一个问题是我们拥有两个堆,全部内存都在这两个独立的堆内往复移动,要求付出的管理量是实际需求的两倍.为办理这个问题,有些JVM按照需求分配内存堆,并将一个堆简单地复制到另一个.

第二个问题是复制.随着程序变得越来越“结实”,它几近不产生或产生很少的垃圾.固然如此,一个副本汇集器仍会将全部内存从一处复制到另一处,这显得非常浪费.为避免这个问题,有些JVM能侦测能否没有产生新的垃圾,并随即改换另一种筹划（这就是“自适应”的缘由）.另一种筹划叫作“标志和排除”,Sun公司的JVM一向采取的都是这种筹划.关于通例性的利用,标志和排除显得非常慢,但一旦知道自己不产生垃圾,大概只产生很少的垃圾,它的速度就会非常快.

标志和排除采取相同的逻辑:从仓库和静态存储区域开始,并跟踪全部句柄,探求活动对象.但是,每次发现一个活动对象的时刻,就会设置一个标志,为那个对象作上“暗号”.但此时髦不汇集那个对象.只有在标志历程完毕,排除历程才正式开始.在排除历程中,死锁的对象会被释放但是,不会举行任何情势的复制,所以假如汇集器决意压缩一个断续的内存堆,它通过移动四周的对象来实现.

“终止和复制”向我们表明这种范例的垃圾汇集并非在后台举行的;相反,一旦发生垃圾汇集,程序就会终止运行.在Sun公司的文档库中,可发现很多地方都将垃圾汇集定义成一种低优先级的后台进程,但它只是一种理论上的实行,实际根本不能工作.在实际利用中,Sun的垃圾汇集器会在内存削减时运行.除此以外,“标志和排除”也要求程序终止运行.

正如早先指出的那样,在这里介绍的JVM中,内存是按大块分配的.若分配一个大块头对象,它会得到自己的内存块.严峻的“终止和复制”要求在释放旧堆之前,将每个活动的对象从源堆复制到一个新堆,此时会触及大量的内存转换工作.通过内存块,垃圾汇集器普通可操纵死块复制对象,就象它举行汇集时那样.每个块都有一个生成计数,用于跟踪它能否仍然“存活”.普通,只有自上次垃圾汇集以来成立的块才会得到压缩;关于其他全部块,假如已从其他某些地方举行了引用,那么生成计数城市溢出.这是很多短时间的、暂时的对象常常碰到的情形.会周期性地举行一次完好排除工作——大块头的对象仍未复制（只是让它们的生成计数溢出）,而那些包含了小对象的块会举行复制和压缩.JVM会监督垃圾汇集器的效率,假如由于全部对象都属于长期对象,造成垃圾汇集成为浪费时间的一个历程,就会切换到“标志和排除”筹划.近似地,JVM会跟踪监督成功的“标志与排除”工作,若内存堆变得越来越“散乱”,就会换回“终止和复制”筹划.“自定义”的说法就是从这种行为来的,我们将其最后总结为:“按照情形,自动转换终止和复制／标志和排除这两种情势”.

JVM还采取了其他很多加快筹划.此中一个分外重要的触及装载器以及JIT编译器.若必须装载一个类（普通是我们初次想成立那个类的一个对象时）,会找到.class文件,并将那个类的字节码送入内存.此时,一个办法是用JIT编译全部代码,但这样做有两方面的缺陷:它会花更多的时间,若与程序的运行时间综合考虑,编译时间还有大概更长;并且它增大了履行文件的长度（字节码比扩大过的JIT代码精简得多）,这有大概造成内存页交换,从而明显放慢一个程序的履行速度.另一种替换办法是:除非确有必要,不然不经JIT编译.这样一来,那些根本不会履行的代码便大概永久得不到JIT的编译.

由于JVM对浏览器来说是外置的,大家大概但愿在利用浏览器的时刻从一些JVM的速度提高中得到好处.但非常不幸,JVM目前不能与差别的浏览器举行沟通.为施展一种特定JVM的潜力,要末利用内建了那种JVM的浏览器,要末只有运行独立的Java利用程序.