3.垃圾回收
从Java发布最早版本开始，一直都保留的核心特性就是垃圾回收，它真是让人又爱又恨。垃圾回收使我们不再需要手动管理内存：当使用完一个对象后，我们只需删除它的引用，然后垃圾回收就会自动释放它。如果你使用过需要手动管理内存的语言，诸如C或C++，你会满怀感激。垃圾回收为程序员们减少了分配、释放内存空间的繁琐步骤。
此外，因为垃圾回收器会自动释放没有引用的内存空间，它减少了传统的内容泄露情况，即内存被分配后，该内存的引用在内存释放前就被删除了。听起来就像灵丹妙药，不是么？
尽管垃圾回收达成了无需手动管理内存的目标，也防止了传统的内存泄露，但是作为代价，垃圾回收过程有时相当笨拙。根据不同的JVM,垃圾回收策略也会不同。深入探讨这些策略超出了本文的主旨。但是，读者应该明白，了解垃圾回收期的工作原理，以及最佳的配置方案至关重要。
垃圾回收最大的敌人就是传说中的主要(major)或(full)垃圾回收。除了Azul JVM，所有的JVM都有这个问题。通常，垃圾回收大致分为两类：
次级
主要
为了释放存活时间较短的对象，次级垃圾回收发生得相对频繁。他们在运行时不会封锁线程，产生的影响较小。
然而，主要垃圾回收，有时也称为“暂停世界(Stop The World, STW)”垃圾回收，因为他们在运行时会封锁JVM中的所有线程。
当垃圾回收运行时，它会运行一项可达性测试(reachability test)，如图四所示。它会创建一个由对象组成的根集合(root set)，该集合包含每个运行线程中的直接可见对象。接着，它会探寻根集合中的对象涉及的其他对象，然后探寻这些对象涉及的对象，直到所有对象都被涉及。在这个过程中，它会记录(mark)下现时活动对象的内存地址，然后把不被使用的所有地址都扫除(sweep)。说得更恰当些，它会把没有根集合对象引用的内存都释放。最终，它会压缩、整理这些内存，这样新的对象才能获得内存分配。
根据不同的JVM，次级、主要回收的方式都会不同。图五图六展示了在Sun JVM内次级、主要回收的操作方式。
在次级回收中，内存主要分配到Eden空间直到将其填满。接着，拷贝收集器(copy collector)会将Eden中的活动对象拷贝到两个幸存者空间(survivor spaces, to space和from space)。遗留在Eden中的对象就会被移除。如果幸存者空间被填满，但还有多余的活动对象，这些对象会被移到tenured空间。只有主要回收才能释放tenured空间的内存。
最终，tenured空间会被填满，主要回收将会执行。它不会将幸存者空间放不下的活动对象拷贝到tenured空间中。此时，JVM会封锁所有线程，运行可达性测试，清除年轻的数据(Eden和两个幸存者空间)，并压缩tenured空间。我们将之称为主要回收。
你或许会想，堆越大，主要回收运行得越不频繁。但是当它执行时，所需时间就会比小堆要长。因此，调整好堆的大小和垃圾回收策略对于应用的性能也很重要。
4.应用布局
最后要探讨的性能指标是应用布局。因为云的出现，现在的应用变得更加灵活：应用环境可以根据用户需求调节大小。因此，对应用的布局进行检测从而决定实例的多少是否合适是非常重要的。如果你的实例太多，你的云主机成本就会增加。但如果你没有足够的实例，商业事务就会受到影响。
在评测过程中，下面两个指标尤其重要：
商业事务的吞吐量
容器性能
商业事务应该基准化，你应该知道在给定的时间里为了满足基准所需的实例数量。如果你的商业事务的吞吐量增长突然，你就要增加实例以满足用户。
另一个需要监测的是容器性能。具体来说，你想确定是否有应用中的实例负载过大，如果有，你或许想在那个应用中添加实例。从应用的角度查看实例状态很重要，因为单个实例可能由于垃圾回收之类的因素负载过大，但如果应用中大多数实例都负载过大，则该应用可能已经无法支持它接受的访问量。
因为应用中的实例可以单个地调节规模，所以分析各个实例的性能进而调整应用布局就至关重要。
