Serial收集器是最基础、 历史最悠久的收集器， 曾经（在JDK 1.3.1之前） 是HotSpot虚拟机新生代收集器的唯一选择。 大家只看名字就能够猜到， 这个收集器是一个单线程工作的收集器， 但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作， 更重要的是强调在它进行垃圾收集时， 必须暂停其他所有工作线程， 直到它收集结束。 “Stop The World”这个词语也许听起来很酷， 但这项工作是由虚拟机在后台自动发起和自动完成的， 在用户不可知、 不可控的情况下把用户的正常工作的线程全部停掉， 这对很多应用来说都是不能接受的。 读者不妨试想一下， 要是你的电脑每运行一个小时就会暂停响应五分钟， 你会有什么样的心情？ 图3-7示意了Serial/Serial Old收集器的运行过程。

对于“Stop The World”带给用户的恶劣体验， 早期HotSpot虚拟机的设计者们表示完全理解， 但也同时表示非常委屈： “你妈妈在给你打扫房间的时候， 肯定也会让你老老实实地在椅子上或者房间外待着， 如果她一边打扫， 你一边乱扔纸屑， 这房间还能打扫完？ ”这确实是一个合情合理的矛盾， 虽然垃圾收集这项工作听起来和打扫房间属于一个工种， 但实际上肯定还要比打扫房间复杂得多！

简单理解这段话的意思就是说，你不能一边让我给你清理垃圾，一边你又在不断制造垃圾吧。

从JDK 1.3开始， HotSpot虚拟机开发团队为消除或者降低用户线程因垃圾收集而导致停顿的努力一直持续进行着， 从Serial收集器Parallel收集器， 再到Concurrent MarkSweep（CMS） 和Garbage First（G1） 收集器， 最终至现在垃圾收集器的最前沿成果Shenandoah和ZGC等， 我们看到了一个个越来越构思精巧， 越来越优秀， 也越来越复杂的垃圾收集器不断涌现， 用户线程的停顿时间在持续缩短， 但是仍然没有办法彻底消除（这里不去讨论RTSJ中的收集器） ， 探索更优秀垃圾收集器的工作仍在继续。

迄今为止， 它依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器， 有着优于其他收集器的地方， 那就是简单而高效（与其他收集器的单线程相比） ， 对于内存资源受限的环境， 它是所有收集器里额外内存消耗（Memory Footprint） [1]最小的； 对于单核处理器或处理器核心数较少的环境来说， Serial收集器由于没有线程交互的开销， 专心做垃圾收集自然可以获得最高的单线程收集效率。 在用户桌面的应用场景以及近年来流行的部分微服务应用中， 分配给虚拟机管理的内存一般来说并不会特别大， 收集几十兆甚至一两百兆的新生代（仅仅是指新生代使用的内存， 桌面应用甚少超过这个容量） ， 垃圾收集的停顿时间完全可以控制在十几、 几十毫秒， 最多一百多毫秒以内， 只要不是频繁发生收集， 这点停顿时间对许多用户来说是完全可以接受的。 所以，Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。

[1] Memory Footprint： 内存占用， 此语境中指为保证垃圾收集能够顺利高效地进行而存储的额外信息。

文章的内容也是<深入理解JAVA虚拟机>这本书中的内容，重点我已经加粗了，方便小伙伴们理解的时候抓住重点。