4.2 Evictor模式
Evictor（清除者）模式描述了何时以及如何释放资源以优化资源管理。这个模式让我们可以配置不同的策略来自动决定哪些资源应该释放，以及应该在什么时候释放这些资源。
1.问题
高度健壮及可伸缩的系统必须高效地管理资源。随着时间的推移，应用程序会获得很多资源，其中有一些只用过一次。如果应用程序持续地获取资源而不释放它们，那么就会导致性能下降和系统的不稳定。为了避免出现这样的情况，应用程序可以在使用资源之后立刻释放资源。但是，应用程序可能需要重新使用相同的资源，这就要求重新获得那些资源。重新获得资源这个操作本身可能代价高昂，所以应该避免，这可以通过把频繁使用的资源保留在内存中来做到。
为了解决这些相互冲突的资源管理需求，我们需要关注以下几点：
1）最优性（Optimality）。使用资源的频率应当影响资源的生命周期。
2）可配置性（Configurability）。应当通过资源类型，可用内存和CPU负载之类的参数来决定资源的释放。
3）透明性（Transparency）。解决方案应该对资源使用者是透明的。
2.解决方案
监控资源的使用，并用某种策略，比如Least Recently Used（LRU）或者Least Frequently Used（LFU）来控制其生命周期。每当资源被使用时，就会被应用程序所标记。当资源最近没有被使用，或者不是频繁被使用时，那么就不会被标记。周期性地，或者根据需要，应用程序会选择那些没有被标记的资源并且释放或者清除它们。被标记的资源会继续留在内存中，因为它们会被频繁使用。
另外，也可以用其他策略来判断应该清除哪些资源。例如，对于内存受限的应用程序，可以用资源的尺寸来决定应该清除哪些资源。在这样的情形下，消费大量内存的资源可能会被清除，哪怕它曾被频繁使用。
3.结构
资源使用者使用资源，它可以包括应用程序或者操作系统。
资源是一个实体，比如提供某种类型的功能的服务。
清除者（Evictor）基于一个或多个清除策略清除资源。
清除策略（Eviction strategy）描述用于判断是否应当清除资源的标准。
4.实现
1）定义清除接口。应该定义一个清除接口，所有能被清除的资源都要实现这个接口。
2）决定可清除的资源。开发者必须决定哪些资源可以并且应该被清除。例如，应用程序总是需要的资源，或者不能重新获取的资源就不应该被清除。任何可以清除的资源必须实现清除接口。在清除资源之前，应用程序应该调用这个接口，给资源一个机会来做“善后”工作，这包括把任何必要的状态持久化。
3）决定清除策略。基于应用程序的需求，可以用不同的清除策略来判断是否清除资源，以及清除哪些可以清除的资源。一些用来判断清除哪些资源的策略包括Least Recently Used（LRU）和Least Frequently Used（LFU）。
此外，可以使用能接受不同参数的用户定义的策略。例如，清除策略可以考虑重新获取被清除的资源的代价有多昂贵。使用这样的策略，重新获取的代价比较低的资源可能会被清除，哪怕它们会比获取起来更昂贵的资源用得更频繁。
4）定义系统中对清除的使用。需要在Evictor中增加清除资源的业务逻辑。这包含判断应该何时以及如何清除资源，以及实现标记要被清除的资源。通常情况下，Evictor在应用程序中作为一个单独对象或者组件而存在，并会被应用程序以必要的清除策略来配置。例如，应用程序可能会选择在可用内存低于某个特定值的时候清除资源。另一个不同的应用程序可能会实现更主动的策略并会周期性地清除策略资源，即便内存没有低于某个值。
5.结论
优点：
1）可伸缩性（Scalability）。Evictor模式允许应用程序对使用的资源的数目保留一个上限，从而在任何给定的时间内都在内存中，这使得应用程序可以伸缩而不影响总体内存消耗。
2）低的内存占用（Low memory foorprint）。Evictor模式允许应用程序通过可配置策略来控制哪些资源应该保留在内存中，哪些资源应该释放。通过只在内存中保留最关键的资源，应用程序可以保持“苗条”，并保持高效。
3）透明性（Transparency）。使用Evictor模式使得资源释放对于资源使用者完全透明。
4）稳定性（Stability）。Evictor模式降低了资源枯竭的可能性，从而增加了应用程序的稳定性。
缺点：
1）额外的开销（Overhead）。Evictor模式需要额外的业务逻辑来判断要清除哪些资源，以及实现清除策略。此外，资源的实现清除也可能会带来明显的执行开销。
2）重新获取的损失（Re-acquisition penalty）。如果再次需要用到被清除的资源，那么就需要重新获取该资源。这可能代价高昂，会影响应用程序的性能。可以通过调整Evictor用来判断清除哪些资源的策略来避免发生这种情况。