JavaEE7并发编程—ConcurrencyUtilities.docVIP

Concurrency Utilities（JSR 166）是一个随Java EE 7版本一同发布的Java EE新标准。该标准描述了Executor API的设计，Executor API随Java 1.5版本引入，作为容器侧管理型对象。 Executor API的相关介绍可以在由Oracle维护的Java SE文档——High Level Concurrency Objects中找到。Executor API向开发者提供一系列的对象实现高效的线程管理。通常来说，这种高效是由一些线程池机制提供的。 线程池 线程池负责创建特定数量的工作线程，并在这些工作线程上运行用户自定义的任务。在这种机制下，最多可运行的用户自定义任务的数量由线程池的大小和系统资源的利用率决定。 上图可以帮助你更好的理解线程池。左侧的代码想用for循环方式在你的程序中创建并执行5000个任务。在不使用线程池的情况下，试图激活这5000个任务将会对系统资源造成威胁。通过查看系统中正在运行的程序内活跃任务（线程）的数量，我们可以更好地来理解威胁的含义。 例如，上图显示了在我的机器上同时运行的一系列进程及其所持有的线程。我们可以清楚的看到应用程序idea.exe持有71个线程，而其他的应用程序则使用了较少的线程。因此，如果我有5000个任务并且为这5000个任务创建了5000个不同的线程，这难道意味着我设计了一个好的架构吗？（当然不是） 事实上，如果我把这5000个任务按照一定规则（随机分配或按优先级分配）安排在特定数量的工作线程上运行，会更高效地利用系统资源而且不会给系统带来不必要的压力。由于上面的图中设定了5个工作线程，这5000个任务在操作系统看来最多只有5个用户自定义任务在运行。当一个工作线程执行结束后，会从当前处于等待状态的任务中选取一个执行，这个过程会持续进行直到所有的任务都执行完成。因此，Java?SE?1.5版本推出的Executor?API的基本原理是通过提供多种线程池环境实现高效的线程管理。工作线程是线程工厂生产的通用线程。 ExecutorService和ScheduledExecutorService是Executor?API中的基本接口。这些接口的实现可能是Executors类的一系列静态方法。Java?EE?7版本推出的新Concurrency?Utilities标准通过容器服务提供这些对象的注入和管理。容器管理的Executor对象以XXXExecutorService和XXXScheduledExecutorService的形式命名，如ManagedExecutorService和ManagedScheduledExecutorService标识了它是可管理的。你可以查看这些接口的UML图，了解Java?SE?Executor?API接口间的继承关系。 以“Managed”开头的接口基本上和Java?1.5版本推出的Executor?API组件提供相同的操作。不同之处在于，其创建的对象将以容器资源（container?resources）的形式提供给开发者。 容器资源是由应用服务器管理的特殊对象。DataSources、JMS?resources以及Concurrency?Utilities中的Concurrency?units都属于容器资源。 容器资源是驻留在应用服务器上并提供特定功能的对象。这些对象可以通过JNDI（Java?Naming?and?Directory?Interfaces）标准进行访问。@Resource注解和Context接口类型的对象（如：InitialContext）基本上可以实现对这些对象的访问。 创建并发资源 支持Java?EE?7版本的应用服务器能够创建Concurrency?Utilities中可管理的Executor对象。例如，这个创建过程可以通过Glassfish?4的asadmin命令集或者Glassfish管理员控制台直观地定义出来。 Glassfish应用服务器/bin目录下的asadmin?tool用于命令行操作。下面的例子使用了asadmin?tool，并通过create-managed-executor-service?命令和create-managed-scheduled-executor-service命令创建可管理的Executor对象。因为容器资源在被提供给应用环境时携带着遵从JNDI标准定义的访问表达式，所以需要在控制台中输入代表该容器资源的唯一访问标识符。 在Glassfish管理员控制台中能够看到可管理的Executor对象。与此同时，在管理员控制台中也能够进行添加和修改。 Glassfish?4的容器资源显示在控制台的Resources标签下。并发资源显示在子标签Co