首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > 编程 >

5.引见java.util.concurrent

2013-12-20 
5.介绍java.util.concurrent5.介绍java.util.concurrentExecutor?是一个简单的标准化接口,用于定义类似于

5.介绍java.util.concurrent
5.介绍java.util.concurrent

Executor?是一个简单的标准化接口,用于定义类似于线程的自定义子系统,包括线程池、异步 IO 和轻量级任务框架。根据所使用的具体 Executor 类的不同,可能在新创建的线程中,现有的任务执行线程中,或者调用?execute()?的线程中执行任务,并且可能顺序或并发执行。ExecutorService?提供了多个完整的异步任务执行框架。ExecutorService 管理任务的排队和安排,并允许受控制的关闭。ScheduledExecutorService?子接口及相关的接口添加了对延迟的和定期任务执行的支持。ExecutorService 提供了

安排异步执行的方法,可执行由?Callable?表示的任何函数,结果类似于?RunnableFuture?返回函数的结果,允许确定执行是否完成,并提供取消执行的方法。RunnableFuture?是拥有?run?方法的 Future,run?方法执行时将设置其结果。

ThreadPoolExecutor?和?ScheduledThreadPoolExecutor?提供可调的、灵活的线程池。Executors?类提供大多数 Executor 的常见类型和配置的工厂方法,以及使用它们的几种实用工具方法。其他基于 Executor 的实用工具包括具体类?FutureTask,它提供 Future 的常见可扩展实现,以及?ExecutorCompletionService,它有助于协调对异步任务组的处理。

?

队列

java.util.concurrent?ConcurrentLinkedQueue?类提供了高效的、可伸缩的、线程安全的非阻塞 FIFO 队列。java.util.concurrent 中的五个实现都支持扩展的?BlockingQueue?接口,该接口定义了 put 和 take 的阻塞版本:LinkedBlockingQueueArrayBlockingQueueSynchronousQueuePriorityBlockingQueue?和?DelayQueue。这些不同的类覆盖了生产者-使用者、消息传递、并行任务执行和相关并发设计的大多数常见使用的上下文。BlockingDeque?接口扩展?BlockingQueue,以支持 FIFO 和 LIFO(基于堆栈)操作。LinkedBlockingDeque?类提供一个实现。

计时

TimeUnit?类为指定和控制基于超时的操作提供了多重粒度(包括纳秒级)。该包中的大多数类除了包含不确定的等待之外,还包含基于超时的操作。在使用超时的所有情况中,超时指定了在表明已超时前该方法应该等待的最少时间。在超时发生后,实现会“尽力”检测超时。但是,在检测超时与超时之后再次实际执行线程之间可能要经过不确定的时间。接受超时期参数的所有方法将小于等于 0 的值视为根本不会等待。要“永远”等待,可以使用?Long.MAX_VALUE?值。

同步器

四个类可协助实现常见的专用同步语句。Semaphore?是一个经典的并发工具。CountDownLatch?是一个极其简单但又极其常用的实用工具,用于在保持给定数目的信号、事件或条件前阻塞执行。CyclicBarrier?是一个可重置的多路同步点,在某些并行编程风格中很有用。Exchanger?允许两个线程在 collection 点交换对象,它在多流水线设计中是有用的。

并发 Collection

除队列外,此包还提供了设计用于多线程上下文中的 Collection 实现:ConcurrentHashMapConcurrentSkipListMapConcurrentSkipListSetCopyOnWriteArrayList?和?CopyOnWriteArraySet。当期望许多线程访问一个给定 collection 时,ConcurrentHashMap?通常优于同步的?HashMapConcurrentSkipListMap?通常优于同步的?TreeMap。当期望的读数和遍历远远大于列表的更新数时,CopyOnWriteArrayList?优于同步的?ArrayList

此包中与某些类一起使用的“Concurrent&rdquo前缀;是一种简写,表明与类似的“同步”类有所不同。例如,java.util.Hashtable?和Collections.synchronizedMap(new HashMap())?是同步的,但?ConcurrentHashMap?则是“并发的”。并发 collection 是线程安全的,但是不受单个排他锁的管理。在 ConcurrentHashMap 这一特定情况下,它可以安全地允许进行任意数目的并发读取,以及数目可调的并发写入。需要通过单个锁不允许对 collection 的所有访问时,“同步”类是很有用的,其代价是较差的可伸缩性。在期望多个线程访问公共 collection 的其他情况中,通常“并发”版本要更好一些。当 collection 是未共享的,或者仅保持其他锁时 collection 是可访问的情况下,非同步 collection 则要更好一些。

大多数并发 Collection 实现(包括大多数 Queue)与常规的 java.util 约定也不同,因为它们的迭代器提供了弱一致的,而不是快速失败的遍历。弱一致的迭代器是线程安全的,但是在迭代时没有必要冻结 collection,所以它不一定反映自迭代器创建以来的所有更新。

内存一致性属性

Java Language Specification 第 17 章定义了内存操作(如共享变量的读写)的?happen-before?关系。只有写入操作?happen-before?读取操作时,才保证一个线程写入的结果对另一个线程的读取是可视的。synchronized?和?volatile?构造?happen-before?关系,Thread.start()?和Thread.join()?方法形成?happen-before?关系。尤其是:

线程中的每个操作?happen-before?稍后按程序顺序传入的该线程中的每个操作。一个解除锁监视器的(synchronized?阻塞或方法退出)happen-before?相同监视器的每个后续锁(synchronized?阻塞或方法进入)。并且因为?happen-before?关系是可传递的,所以解除锁定之前的线程的所有操作?happen-before?锁定该监视器的任何线程后续的所有操作。写入?volatile?字段?happen-before?每个后续读取相同字段。volatile?字段的读取和写入与进入和退出监视器具有相似的内存一致性效果,但不?需要互斥锁。在线程上调用?start?happen-before?已启动的线程中的任何线程。线程中的所有操作?happen-before?从该线程上的?join?成功返回的任何其他线程。

java.util.concurrent?中所有类的方法及其子包扩展了这些对更高级别同步的保证。尤其是:

    线程中将一个对象放入任何并发 collection 之前的操作?happen-before?从另一线程中的 collection 访问或移除该元素的后续操作。线程中向?Executor?提交?Runnable?之前的操作?happen-before?其执行开始。同样适用于向?ExecutorService?提交?Callables。异步计算(由?Future?表示)所采取的操作?happen-before?通过另一线程中?Future.get()?获取结果后续的操作。“释放”同步储存方法(如?Lock.unlockSemaphore.release?和?CountDownLatch.countDown)之前的操作?happen-before?另一线程中相同同步储存对象成功“获取”方法(如?Lock.lockSemaphore.acquireCondition.await?和?CountDownLatch.await)的后续操作。对于通过?Exchanger?成功交换对象的每个线程对,每个线程中?exchange()?之前的操作?happen-before?另一线程中对应?exchange()?后续的操作。调用?CyclicBarrier.await?之前的操作?happen-before?屏障操作所执行的操作,屏障操作所执行的操作?happen-before?从另一线程中对应await?成功返回的后续操作。Condition

    Condition?将?Object?监视器方法(waitnotify?和?notifyAll)分解成截然不同的对象,以便通过将这些对象与任意?Lock?实现组合使用,为每个对象提供多个等待 set(wait-set)。其中,Lock?替代了?synchronized?方法和语句的使用,Condition?替代了 Object 监视器方法的使用。

    条件(也称为条件队列?或条件变量)为线程提供了一个含义,以便在某个状态条件现在可能为 true 的另一个线程通知它之前,一直挂起该线程(即让其“等待”)。因为访问此共享状态信息发生在不同的线程中,所以它必须受保护,因此要将某种形式的锁与该条件相关联。等待提供一个条件的主要属性是:以原子方式?释放相关的锁,并挂起当前线程,就像?Object.wait?做的那样。

    Condition?实例实质上被绑定到一个锁上。要为特定?Lock?实例获得?Condition?实例,请使用其?newCondition()?方法。

    作为一个示例,假定有一个绑定的缓冲区,它支持?put?和?take?方法。如果试图在空的缓冲区上执行?take?操作,则在某一个项变得可用之前,线程将一直阻塞;如果试图在满的缓冲区上执行?put?操作,则在有空间变得可用之前,线程将一直阻塞。我们喜欢在单独的等待 set 中保存?put?线程和?take?线程,这样就可以在缓冲区中的项或空间变得可用时利用最佳规划,一次只通知一个线程。可以使用两个?Condition?实例来做到这一点。

     class BoundedBuffer {   final Lock lock = new ReentrantLock();   final Condition notFull  = lock.newCondition();    final Condition notEmpty = lock.newCondition();    final Object[] items = new Object[100];   int putptr, takeptr, count;   public void put(Object x) throws InterruptedException {     lock.lock();     try {       while (count == items.length)          notFull.await();       items[putptr] = x;        if (++putptr == items.length) putptr = 0;       ++count;       notEmpty.signal();     } finally {       lock.unlock();     }   }   public Object take() throws InterruptedException {     lock.lock();     try {       while (count == 0)          notEmpty.await();       Object x = items[takeptr];        if (++takeptr == items.length) takeptr = 0;       --count;       notFull.signal();       return x;     } finally {       lock.unlock();     }   }  }

    ?

    ArrayBlockingQueue?类提供了这项功能,因此没有理由去实现这个示例类。)

    Condition?实现可以提供不同于?Object?监视器方法的行为和语义,比如受保证的通知排序,或者在执行通知时不需要保持一个锁。如果某个实现提供了这样特殊的语义,则该实现必须记录这些语义。

    注意,Condition?实例只是一些普通的对象,它们自身可以用作?synchronized?语句中的目标,并且可以调用自己的?wait?和notification?监视器方法。获取?Condition?实例的监视器锁或者使用其监视器方法,与获取和该?Condition?相关的?Lock?或使用其?waiting?和?signalling?方法没有什么特定的关系。为了避免混淆,建议除了在其自身的实现中之外,切勿以这种方式使用Condition?实例。

    除非另行说明,否则为任何参数传递?null?值将导致抛出?NullPointerException

    ?

    实现注意事项

    在等待?Condition?时,允许发生“虚假唤醒”,这通常作为对基础平台语义的让步。对于大多数应用程序,这带来的实际影响很小,因为?Condition?应该总是在一个循环中被等待,并测试正被等待的状态声明。某个实现可以随意移除可能的虚假唤醒,但建议应用程序程序员总是假定这些虚假唤醒可能发生,因此总是在一个循环中等待。

    三种形式的条件等待(可中断、不可中断和超时)在一些平台上的实现以及它们的性能特征可能会有所不同。尤其是它可能很难提供这些特性和维护特定语义,比如排序保证。更进一步地说,中断线程实际挂起的能力在所有平台上并不是总是可行的。

    因此,并不要求某个实现为所有三种形式的等待定义完全相同的保证或语义,也不要求其支持中断线程的实际挂起。

    要求实现清楚地记录每个等待方法提供的语义和保证,在某个实现不支持中断线程的挂起时,它必须遵从此接口中定义的中断语义。

    由于中断通常意味着取消,而又通常很少进行中断检查,因此实现可以先于普通方法的返回来对中断进行响应。即使出现在另一个操作后的中断可能会释放线程锁时也是如此。实现应记录此行为。

    ?

    Executor CachedThreadPool? FixedThreadPool? SingleTreadExecutors

    ?Executors.newCachedThreadPool(); //带缓存的 不够时自动添加
    ?Executors.newSingleThreadExecutor(); //单个线程池? 线程死掉后自动创建
    ?Executors.newFixedThreadPool(10);? //创建容纳N个线程的
    ?Executors.newScheduledThreadPool(19); //创建定时器线程池

    shutdown():用于关闭启动线程,如果不调用该语句,jvm不会关闭。

    awaitTermination():用于等待子线程结束,再继续执行下面的代码。该例中我设置一直等着子线程结束。

    Lock lock = new ReentrantLock(); //lock 互斥锁 对象
    Condition condition = lock.newCondition(); // 条件. 通讯对象
    Condition?? ??? ?//条件锁
    Semaphore ?? ??? ?//信号量 类似执行授权 (最多有3个人可以走)
    CyclicBarrier ?? ?//类似集合点 (必须3个人同时到才能走)
    CountDownLatch?? ?//计数器 计时器效果 某时间点同时执行 CountDownLath a = new CountDownLath(1); a.await(); a.countDown();
    Exchanger?? ??? ?//数据交换 Exchanger a = new Exchanger()//放主线程; a.exchange("asd")

    ArrayBlockingQueue?? ??? ??? ?//阻塞队列? ArrayBlockingQueue 啊 = new ArrayBlockingQueue(); a.put(1);//阻塞 a.add(1);?? ?//a.tack(); 获取

热点排行