传统的C/C++等编程语言，需要程序员负责回收已经分配的内存。显式进行垃圾回收是一件比较困难的事情，因为程序员并不总是知道内存应该何时被释放。如果一些分配出去的内存得不到及时回收，就会引起系统运行速度下降，甚至导致程序瘫痪，这种现象被称为内存泄漏。总体而言，显式进行垃圾回收主要有如下两个缺点：
A．程序忘记及时回收无用内存，从而导致内存泄漏，降低系统性能。
B．程序错误地回收程序核心类库的内存，从而导致系统崩溃。
与C/C++程序不同，Java语言不需要程序员直接控制内存回收，Java程序的内存分配和回收都是由JRE在后台自动进行的。JRE会负责回收那些不再使用的内存，这种机制被称为垃圾回收（Garbage Collection，也被称为GC）。通常JRE会提供一条后台线程来进行检测和控制，一般都是在CPU空闲或内存不足时自动进行垃圾回收，而程序员无法精确控制垃圾回收的时间和顺序等。
实际上，垃圾回收机制不可能实时检测到每个Java对象的状态，当一个对象失去引用后，它也不会被立即回收，只有等接下来垃圾回收器运行时才会被回收。
对于一个垃圾回收器的设计算法来说，大致有如下可供选择的设计：
A．串行回收（Serial）和并行回收（Parallel）：串行回收就是不管系统有多少个CPU，始终只用一个CPU来执行垃圾回收操作；而并行回收就是把整个回收工作拆分成多部分，每个部分由一个CPU负责，从而让多个CPU并行回收，并行回收的执行效率很高，但复杂度增加，另外也有其他一些副作用，比如内存碎片会增加。
B．并发执行（Concurrent）和应用程序停止（Stop-the-world）：。Stop-the-world的垃圾回收方式在执行垃圾回收的同时会导致应用程序的暂停。并发执行的垃圾回收虽然不会导致应用程序的暂停，但由于并发执行垃圾回收需要解决和应用程序的执行冲突（应用程序可能会在垃圾回收的过称中修改对象），因此并发执行垃圾回收的系统开销比Stop-the-world更好，而且执行时也需要更多的堆内存。
C．压缩（Compacting）和不压缩（Non-compacting）和复制（Copying）：为了减少内存碎片，支持压缩的垃圾回收器会把所有的活对象搬迁到一起，然后将之前占用的内存全部回收。不压缩式的垃圾回收器只是回收内存，这样回收回来的内存不可能是连续的，因此将会有较多的内存碎片。较之压缩式的垃圾回收，不压缩式的垃圾回收回收内存快了，而分配内存时就会更慢，而且无法解决内存碎片的问题。复制式的垃圾回收会将所有可达对象复制到另一块相同的内存中，这种方式的优点是垃圾及回收过程不会产生内存碎片，但缺点也很明显，需要拷贝数据和额外的内存。