隐形耦合关系

[水灵]

  我们已经知道，Executor框架可以将任务的提交与任务的执行策略解耦开来。这为制定和修改执行策略等操作提供了相当大的灵活性，但并非所有的任务都能适用所有的执行策略。有些类型的任务需要明确地指定执行策略，其中包括：

• 依赖性任务。大多数行为正确的任务都是独立的：它们不会依赖于其它任务的执行时序、 执行结果或者其它任务的其他效果。当在线程池中执行独立的任务时，使用者可以随意地改变线程池的大小和配置， 不过这些修改只会对执行性能产生影响。 然而，如果提交给线程池的任务需要依赖其他的任务， 那么就隐含地给执行策略带来了约束，当给执行策略带来约束的时候就必须要小心地维持这些执行策略以避免产生活跃性问题。

• 使用线程封闭机制的任务。与线程池相比， 单线程的Executor能够对并发性做出更强的承诺。 它们能确保任务不会并发地执行， 使你能够对线程安全的要求进行放宽。 对象可以封闭在任务线程中，以此来使该线程中执行的任务在访问该对象时不需要同步， 即使这些资源不是线程安全的也没有问题。 这种情形将在任务与执行策略之间形成隐式的耦合---任务要求其执行所在的Executor是单线程的e。如果将Executor从单线程环境改为线程池环境， 那么将会失去线程安全性。
   

• 对响应时间敏感的任务。如果Executor中得到一个运行时间比较长的任务或者一时间内得到多个运行时间比较长的任务时，就会降低Executor的服务响应性。
  使用ThreadLocal的任务：ThreadLocal会使每个线程都可以拥有某个变量的一个私有“版本“。然而，只要条件允许，Executor框架可以自由地重用这些线程，能够很好的节省一部分时间。在标准的Executor实现中，当执行需求较低时将回收空闲线程，而当需求增加时将添加新的线程，并且如果从任务中抛出了一个未检查异常，那么将用一个新的工作者线程来替代抛出异常的线程。只有当线程本地值 的生命周期受限于任务的生命周期时，在线程池的线程中使用ThreadLocal才有意义，而在线 程池的线程中不应该使用 ThreadLocal在任务之间传递值。

  只有当任务都是同类型的并且相互独立时，线程池的性能才能达到最佳。如果将运行时间较长的与运行时间较短的任务混合在一起，那么除非线程池很大，否则将可能造成 “拥塞 ”。如果提交的任务依赖于其他任务，那么除非线程池无限大，否则将可能造成死锁。