传统的C/C++等编程语言,需要程序员负责回收已经分配的内存。显示进行垃圾回收是一件比较困难的事情,因为程序员并不总是知道内存应该何时被释放。如果一些分配出去的内存得不及时回收,就会引起系统运行速度下降,甚至导致程序瘫痪,这种现象被称为内存泄漏。总体而言,显示进行垃圾回收主要有如下两个缺点:

     1.程序忘记及时回收无用内存,从而导致内存泄漏,降低系统性能。

   2.程序错误地回收程序核心类库地内存,从而导致系统崩溃。

        与 C/C++程序不同,Java 语言不需要程序员直接控制内存回收,Java 程序的内存分配和回收都是由JRE(JAVA运行时环境)在后台自动进行的。JRE 会负责回收那些不再使用的内存,这种机制被称为垃圾回收(CrarbgrgSolection,GC)。通常 JRE会提供一个后台线程来进行检测和控制。一感都是在CPU空闲或内存不足时自动进行垃圾回收,而程序员无法精确控制垃圾回收的时间和顺序等。

        Java 的推内存是一个运行时数据区,用以保存类的实例(对象),Java虚拟机的堆內存中存储着正在运行的应用程序所建立的所有对象,这些对象不需要程序通过代码来显示地释放。一般来说,堆内存的回收由垃圾回收器来负责,所有的JVM 实现都有一个由垃圾回收器管理的堆內存。垃圾回收是一种动态储存管理技术,它自动形放不再被程序引用地对象,技照特定的垃圾回收算法来实现内存资源的自动回收功能。
         在C/C++中,对象所占用的内存不会被自动释放,如果程序没有显式释放对象所占用的内存,对象所占用的内存就不能分配给其他对象,该内存在程序结束运行之前将一直被占用:而在Java 中,当没有引用变量指向原先分配给某个对象的内存时。该内存便成为垃圾。JVM的一个超级线程会自动释放该内存区。垃圾回收意味着程序不再需要的对象是“垃圾信息”这些信息将被丢弃。
           当一个对象不再被引用时,内存回收它占领的空间,以便空间被后来的新对象使用。事实上,除释放没用的对象外,垃圾回收也可以清除内存记录碎片。由于创建对象和垃圾回收器释放丢弃对象所占的内存空间,内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存区,碎片整理将所占用的堆内存移到堆的一端,JVM将整理出的内存分配给新的对象。
   垃圾回收能自动释放内存空间,减轻编程的负担,这使Java 虚拟机具有两个显著的优点。
        >垃圾回收机制可以很好地提高编程效率。在没有垃圾回收机制时,可能要花许多时间来解決一个难懂的存储器问题。在用Java语言编程时,依靠垃圾回收机制可大大缩短时间。
       >垃圾回收机制保护程序的完整性,垃圾回收是Java 语言安全性策略的一个重要部分。
        垃圾回收的一个潜在缺点是它的开销影响程序性能。Java 虚拟机必须跟踪程序中有用的对象,才可以确定哪些对象是无用的对象,并最终释放这些无用的对象。这个过程需要花费处理器的时间。其次是垃圾回收算法的不完备性,早先采用的某些垃圾回收算法就不能保证100%收集到所有的废弃内存。当然,随着垃坡回收算法的不断改进,以及软硬件运行效率的不断提升,这些问题都可以迎刃而解。
        Java 语言规范没有明确地说明JVM使用哪种垃圾回收算法,但是任何一种垃圾回收算法一般要做两件基本的事情:1.发现无用的对象2.回收被无用对象占用的内存空间,使该空间可被程序再次使用。
       通常,垃圾回收具有如下几个特点。
       >垃圾回收器的工作目标是回收无用对象的内存空间,这些内存空间都是JVM堆内存里的内存空间,垃圾回收器只能回收内存资源,对其他物理资源,如数据库连接,磁盘 I/O 等资源则无能为 。
       >为了更快地让垃圾回收器回收那些不再使用的对象,可以将该对象的引用变量设置为 null,通过这种方式暗示垃圾回收器可以回收该对象。
       >垃圾回收发生的不可预知性。由于不同JVM采用了不同的垃圾回收机制和不同的垃圾回收算法,因此它有可能是定时发生的,有可能是当CPU空闲时发生的,也有可能和原始的垃圾回收一样,等到内存消耗出现极限时发生,这和垃圾回收实现机制的选择及具体的设置都有关系。虽然程序员可以通过调用 Runtime 对象的 gc()或 System.gc()等方法来建议系统进行垃极回收,但这种调用仅仅是建议,依然不能精确控制垃圾回收机制的执行。
       >垃圾回收的精确性主要包括两个方面:一是垃极回收机制能够精确地标记活者的对象;二是垃圾回收器能够精确的定位对象之间的引用关系,前者是完全回收所有废弃对象的前提,否则就能造成内存泄露;而后者则是实现归并和复制等算法的必要条件,通过这种引用关系,可以保证所有对象都能被可靠地回收,所有对象都能够重新分配。从而有效的减少内存碎片的产生。
      >现在的JVM 有多种不同的垃圾回收实现,每种回收机制因其算法差异可能表现各异。有的当垃圾回收开始时就停止应用程序的运行,有的当垃圾回收运行时允许应用程序的线程运行,还有的在同一时间允许垃圾回收多线程运行。

     当编写 Java 程序时,一个基本原则是:对于不再需要的对象,不要引用它们。如果保持对这些种象的引用,垃圾回收机制暂时不会回收该对象,则会导致系统可用内存越来越少;当系统可用内存越来越少时,垃圾回收执行的频率就越来越高,从而导致系统的性能下降。
    2011年7月发布的Java 7 提供了G1垃圾回收器来代替原有的并行标记/清除垃圾回收器(简种CMS)。并宣布在未来的日子里,G1垃圾回收器将会逐渐取代原有的CMS垃圾回收器。
    2014年3月发布的 Java 8删除了 HotSpot JVM 中的永生代内存(PermGen,永生代内存主要用于存储一些需要常驻内存、通常不会被回收的信息),而是改为使用本地内存来存储类的元数据信息,并将之称为:元空间(Metaspace),这意味着以后不会再遇到 java.lang.OutOfMemoryEror:PermGen 错误(曾经令许多Java 程序员头痛的错误)。
    2017年9月发布的Java9彻底删除了传统的CMS 垃圾回收器,因此运行JVM的 DefNew + CMS.ParNew + SerialOld、Incremental CMS 等组合全部失效。java 命令(该命令负责启用JVM运行Java 程序)以前支持的以下GC相关选项全部被删除。
  >-Xincgc
  > -XX:+CMSIncrementalMode
  >-XX:+UseCMSCompactAtFullCollection
  > -XX:+CMSFullGCsBeforeCompaction
  > -XX:+UseCMSCollectionPassing
  此外,-XX:+UseParNewGC 选项也被标记为过时,将来也会被删除。
  Java 9默认采用低暂停(low-pause)的Gl垃圾回收器,并为G1垃圾回收器自动确定了几个重要的参数设置,从而保证GI垃圾回收器的可用性、确定性和性能。如果部署项目时为 java 命令指定了
-XX:+UseConcMarkSweepGC选项希望启用 CMS垃圾回收器,系统会显示警告信息。
  Java 11 则再次引入了新的、实验性的z垃圾回收器(简称 ZGC),这个垃圾回收器具有以下几个优点。
  > 垃圾回收时暂停时间不会超过10ms。
   > 暂停时间不会随着堆或实时集合的大小而增加。
  >可处理几百MB到几 TB 的堆内存。
      由于 ZGC的核心是并发垃圾回收器,这意味官可在Java线程继续执行时,完成所有的繁重工作(如标记、压缩、引用处理、表清理等),从而大大降低了该垃圾回收器对程序响应速度的影响。
   由于 ZGC在Java 11 中还处于实验性阶段〈在未米可能取代G1 垃圾回收器),因此 Java 默认并未启用 ZGC 垃圾回收器。如果希望运行 Java 程序时启用 ZGC垃圾回收器,则可在运行 java.命令时使用如下选项。
  > -XX:+UnlockExperimentalVMOptions
  > -XX:+UseZGC
  目前ZGC 垃圾回收器只能在64位的Linux 平台上使用。
  此外,Java 11还引入了实验性的Epsiion 垃圾回收器。严格来说。Epsilon 并不算真正的垃圾回收器,它只负责内存分配,并不负责内存回收。因此,这个垃圾回收器主要在性能测试中比较有用,用于与其他垃圾回收器的开销/收益比进行对比。