Package java.util.concurrent Description(介绍)

Executor

Interfaces. Executor is a simple standardized（标准） interface for defining custom thread-like（线程结构） subsystems（Executor 是定义自定义线程子系统一个简单的标准化接口）, including thread pools（线程池）, asynchronous I/O, and lightweight task frameworks（包括线程池、异步I/O和轻量级任务框架）. Depending（根据） on which concrete（具体） Executor class is being used, tasks may execute in a newly（最近） created thread, an existing（现有） task-execution thread, or the thread calling execute, and may execute sequentially（顺序） or concurrently（同时）（根据正在使用的具体执行器类，任务可以在新创建的线程、现有任务执行线程或调用执行的线程中执行，并且可以按顺序或并发执行）. ExecutorService provides a more complete asynchronous task execution framework. An ExecutorService manages queuing（排队） and scheduling of tasks, and allows controlled（控制） shutdown. The ScheduledExecutorService subinterface and associated（相关） interfaces add support for delayed（延迟） and periodic（周期） task execution. ExecutorServices provide methods arranging（安排） asynchronous execution of any function expressed as Callable（http://blog.csdn.net/xtwolf008/article/details/7713580）, the result-bearing analog（模拟） of Runnable. A Future returns the results of a function（返回一个函数的结果）, allows determination（决定） of whether是否 execution has completed, and provides a means to cancel execution. A RunnableFuture is a Future that possesses a run method that upon execution, sets its results（RunnableFuture 是Future的一个执行run方法设置返回值）.
Implementations（启动）. Classes ThreadPoolExecutor and ScheduledThreadPoolExecutor provide tunable（可调）, flexible（灵活的） thread pools. The Executors class provides factory methods for the most common kinds（类） and configurations（配置） of Executors, as well as a few（很少） utility（效用） methods for using them. Other utilities based（基于） on Executors include the concrete（具体） class FutureTask providing a common extensible（可扩展的） implementation（实现） of Futures, and ExecutorCompletionService, that assists（帮助） in coordinating（协调） the processing of groups of asynchronous tasks.

Class ForkJoinPool provides an Executor primarily（主要） designed for processing instances of ForkJoinTask and its subclasses（ForkJoinPool 提供执行器主要用于ForkJoinTask 及其子类处理实例）. These classes employ a work-stealing scheduler that attains high throughput for tasks conforming to restrictions that often hold in computation-intensive parallel processing（这些类使用一个工作窃取的调度器,达到高吞吐量为符合限制,通常在计算密集型任务并行处理。）.

Queues

The ConcurrentLinkedQueue class supplies（提供） an efficient(有效率的) scalable（可扩展） thread-safe（线程安全） non-blocking（非阻塞） FIFO queue. The ConcurrentLinkedDeque class is similar, but additionally（此外） supports the Deque（双向队列） interface.
Five implementations in java.util.concurrent support the extended BlockingQueue interface, that defines blocking versions of put and take（定义版本会阻塞）: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, PriorityBlockingQueue, and DelayQueue. The different（不同） classes cover the most common usage contexts for producer-consumer, messaging, parallel(并行) tasking, and related concurrent designs.

Extended interface TransferQueue, and implementation LinkedTransferQueue introduce（介绍） a synchronous（同步） transfer method (along with related features) in which a producer may optionally block awaiting its consumer.

The BlockingDeque interface extends BlockingQueue to support both FIFO and LIFO (stack（堆栈）-based（基于）) operations. Class LinkedBlockingDeque provides（提供） an implementation（实现）.

Timing

The TimeUnit class provides multiple granularities（粒度） (including nanoseconds（纳秒）) for specifying（指定） and controlling（控制） time-out based（基于） operations（操作）. Most classes in the package contain（包含） operations based on time-outs in addition to(除了) indefinite waits. In all cases that time-outs are used, the time-out specifies the minimum（最低） time that the method should wait before indicating that it timed-out（超时指定的最低时间方法表明它之前应该等待超时）. Implementations make a “best effort（努力）” to detect（发现） time-outs as soon（立刻） as possible（发生的） after they occur（实现做出“尽力而为”立刻发现超时）. However（然而）, an indefinite（不确定） amount（计数） of time may elapse（流逝） between a time-out being detected and a thread actually executing again after that time-out（在超时检测到的超时和在该超时后再次实际执行的线程之间，可能会经过时间的数量）. All methods that accept（ 接受） timeout parameters treat values less than or equal to zero to mean not to wait at all（接受超时参数的所有方法都将小于或等于0的值视为不等待）. To wait “forever”, you can use a value of Long.MAX_VALUE.

Synchronizers

Five classes aid common special-purpose synchronization idioms.

• Semaphore is a classic concurrency tool.
• CountDownLatch is a very simple yet very common utility for blocking until a given number of signals, events, or conditions hold.
• A CyclicBarrier is a resettable multiway synchronization point useful in some styles of parallel programming.
• A Phaser provides a more flexible（灵活的） form of barrier that may be used to control phased(分阶段) computation among(在..中间) multiple threads.（提供了一种更灵活形式的障碍，可用于在多线程中控制分阶段计算。）
• An Exchanger allows two threads to exchange objects at a rendezvous point, and is useful（有用的） in several（几个） pipeline designs.

Concurrent Collections

Besides（除此之外） Queues, this package supplies Collection implementations designed for use in multithreaded contexts（该包提供了设计用于多线程上下文的Collection实现）: ConcurrentHashMap, ConcurrentSkipListMap, ConcurrentSkipListSet, CopyOnWriteArrayList, and CopyOnWriteArraySet. When many threads are expected（预期） to access(使用) a given（给予） collection, a ConcurrentHashMap is normally（正常,通常） preferable(更好的) to a synchronized HashMap, and a ConcurrentSkipListMap is normally preferable to a synchronized TreeMap. A CopyOnWriteArrayList is preferable to a synchronized ArrayList when the expected(预期) number of reads and traversals greatly outnumber the number of updates to a list(当预期的读取和遍历次数大大超过列表的更新次数。).
The “Concurrent” prefix used with some classes in this package is a shorthand indicating several differences from similar “synchronized” classes(与此包中某些类使用的“并发”前缀是一个简写，表示与类似“同步”类的几个差异). For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. But ConcurrentHashMap is “concurrent”. A concurrent collection is thread-safe, but not governed by a single exclusion(排斥) lock(但不是由一个单一的排斥锁). In the particular(个别项目) case of ConcurrentHashMap, it safely permits(安全许可证) any number of concurrent reads as well as a tunable(可调) number of concurrent writes. “Synchronized” classes can be useful when you need to prevent(防止) all access（使用） to a collection via（通过） a single lock（当您需要通过单个锁定所有访问到集合时，“同步”类可以很有用）, at the expense of poorer scalability（代价是可扩展性较差）. In other cases in which multiple threads are expected（预期） to access（使用） a common collection, “concurrent” versions are normally preferable（通常更可取的）. And unsynchronized（不同步） collections are preferable when either collections are unshared（非共享）（而当两个集合都是非共享的时候，非同步集合是比较好的）, or are accessible only when holding other locks.（或只能在握住其他锁时才可以访问。）

Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal:
大多数并发Collection实现（包括大多数Queues）也与通常的java.util.conventions不同，因为它们的迭代器和分割器提供弱一致而不是快速失败遍历：

• they may proceed(继续) concurrently(同时) with other operations
• they will never(从来不) throw ConcurrentModificationException
• they are guaranteed(保证) to traverse(通过，障碍） elements as they existed（存在） upon（在..之上） construction exactly once(完全一次), and may (but are not guaranteed(保证) to) reflect(体现) any modifications修改 subsequent(后来的) to construction（结构,）（可能（但不保证）体现修改后的结构）.

Memory Consistency Properties

Chapter 17 of the Java Language Specification（规范） defines（确定,限定,明确） the happens-before relation on memory operations such as reads and writes of shared variables（Java规范的第17章定义了存储器操作之前的发生关系，例如共享变量的读取和写入。）. The results of a write by one thread are guaranteed（保证） to be visible to a read by another thread only if the write operation happens-before the read operation（只有在写操作发生之前，一个线程的写入结果才被保证才能被另一个线程读取。）. The synchronized and volatile（易变的） constructs（构造）, as well as the Thread.start() and Thread.join() methods, can form happens-before relationships（关系）. In particular（特定,特别,特殊）:

• Each action in a thread happens-before every action in that thread that comes later in the program’s order（在线程中的每个动作发生在该线程中的每个动作之前，程序的顺序将稍后）.
• An unlock (synchronized block or method exit) of a monitor（监控） happens-before every subsequent（后来的） lock (synchronized block or method entry) of that same monitor（在监视器的一个解锁（同步块或方法退出）发生在同一监视器的每个后续锁（同步块或方法条目）之前）. And because the happens-before relation is transitive, all actions of a thread prior to unlocking happen-before all actions subsequent to any thread locking that monitor.
• A write to a volatile field happens-before every subsequent read of that same field. Writes and reads of volatile fields have similar memory consistency effects as entering and exiting monitors, but do not entail mutual exclusion locking.
• A call to start on a thread happens-before any action in the started thread.

• All actions in a thread happen-before any other thread successfully returns from a join on that thread.

  The methods of all classes in java.util.concurrent and its subpackages extend these guarantees to higher-level synchronization. In particular:

• Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread.
• Actions in a thread prior to the submission of a Runnable to an Executor happen-before its execution begins. Similarly for Callables submitted to an ExecutorService.
• Actions taken by the asynchronous computation represented by a Future happen-before actions subsequent to the retrieval of the result via Future.get() in another thread.
• Actions prior to “releasing” synchronizer methods such as Lock.unlock, Semaphore.release, and CountDownLatch.countDown happen-before actions subsequent to a successful “acquiring” method such as Lock.lock, Semaphore.acquire, Condition.await, and CountDownLatch.await on the same synchronizer object in another thread.
• For each pair of threads that successfully exchange objects via an Exchanger, actions prior to the exchange() in each thread happen-before those subsequent to the corresponding exchange() in another thread.
• Actions prior to calling CyclicBarrier.await and Phaser.awaitAdvance (as well as its variants) happen-before actions performed by the barrier action, and actions performed by the barrier action happen-before actions subsequent to a successful return from the corresponding await in other threads.

Since:

1.5