Concurrency: Terminating tasks

Terminating tasks

1. The Ornamental Garden

  下面的例子使用标志canceled主动停止任务:

Entrancecancel()会设置canceledtrue,之后run()中的循环(while(!canceled))就会停止,任务结束。这里对canceled的操作只有赋值和读取,都是原子操作,不会被打断,所以只需把canceled设置为volatile保证可见性,不需要使用同步。

  在OrnamentalGardenmain()中结束任务时,首先使用Entrance.cancel()让各任务停止循环,结束各自的run()。然后调用了exec.shutdown()exec.awaitTermination()exec.awaitTermination()用于在一段时间内等待各个任务完成,如果任务能够在时限内(这里是250毫秒)完成,则返回true;否则返回false,表示还有任务没有完成。

  这里所有的Entrance的实例都被添加到了一个静态的列表List<Entrance> entrances中,所以在各个Entrance任务完成之后,各Entrance实例不会被回收,还可以通过entrances来进行访问。

2. Terminating When Blocked

  上面的例子中,任务在执行的过程中检查标志位,主动结束任务。如果当前线程被sleep()等操作阻塞,就需要使用其他方法来结束任务。

2.1. Thread states

  线程有以下四种状态:

  1. New: 线程在被创建时才会短暂地处于这一状态,进行系统资源分配和初始化,之后就会进入Runnable或者Blocked状态。
  2. Runnable: 线程处于可运行的状态,线程接受线程调度的控制,可能处于正在运行的状态,也可能没有在运行。
  3. Blocked: 线程可以运行,但是运行被阻止。线程调度会跳过该状态下的线程,直到线程返回Runnable状态。
  4. Dead: 线程的任务已经运行结束,如run()方法返回,或者被打断。此时线程不再接受调度。

2.2. Becoming Blocked

  以下原因会导致线程进入Blocked状态:

  • 调用sleep(),使线程休眠指定的时间;
  • 调用wait(),使线程被挂起,直到notify()notifyAll()(或者signal()signalAll());
  • 任务在等待I/O操作结束;
  • 任务调用其他对象上的同步方法,但该对象的锁被其他任务占用,暂时无法获得。

  在旧代码中可能还会使用suspend()resume()来阻塞和继续线程,但现在已被废弃。stop()在结束线程时,不会释放线程已经获得的对象的锁定,也已经被废弃。

3. Interruption

  抛出异常会打断run()的执行。Thread类提供了interrupt()方法来打断线程上任务的执行,即便线程处于阻塞状态。interrupt()会设置线程的interrupted标志。设置了interrupted标志的线程,如果已经处于阻塞状态,或者将要执行会导致阻塞的操作时,会抛出InterruptedException异常。异常抛出后,interrupted标志会被复位。

  interrupt()Thread的方法,但Executors避免了对Thread对象的直接操作。ExecutorshutdownNow()会调用该Executor启动的所有线程的interrupt()方法。如果只是希望中断Executor中的特定任务,就不能使用execute()来直接开始任务,而是要使用submit()来获得一个代表了任务上下文的Future<?>Future<?>cancel()会调用对应线程的interrupt()

上面的例子中,Interruptingtest()使用Future f = exec.submit(r),通过submit()提交任务给ExecutorService,并获取返回的Future。在任务运行一段时间后,调用f.cancel(true)中断任务。SleepBlocked使用sleep()产生阻塞,被中断时可以捕获到InterruptedException异常,然后任务被中断。IOBlocked通过等待I/O输入产生阻塞,SynchronizedBlocked通过同步机制产生阻塞,二者不能被中断。

## 3.1. Blocked by I/O

  中断I/O产生的阻塞的一种方法是关闭产生阻塞的资源。

这里使用了ServerSocketInputStream两种InputStreamexec.shutdownNow()并不能中断二者产生的阻塞。通过socketInput.close()System.in.close()关闭InputStream后,对应的任务捕获到IOException异常,之后可以检查到interruptedtrue,说明interrupt()已经生效。

  注意上面的输入来自Thinking in Java原书。在我的电脑上(Windows 10 x64 + JDK 8),上面的例子只有socketInput对应的任务能够在socketInput.close()后检查到interruptedtrue;在System.in.close()后,System.in对应的任务仍处于阻塞状态,当在控制台进行任意输入并回车后,System.in对应的任务被中断,且也能检查到interruptedtrue,如上面例子后的Output所示。

  使用nio相关类可以更加优雅地打断I/O造成的阻塞:

可见通过f.cancel(true)中断任务会捕获到ClosedByInterruptException,通过sc2.close()中断任务会捕获到AsynchronousCloseException,两种方法都可以成功地中断任务。

3.2. Blocked by a Mutex

  如果一个任务调用已经被锁定的对象上的方法,该任务就会被阻塞,直到它成功获得对象的锁定。同一个任务可以反复获得同一个对象的锁定。

f1()首先获得了锁定,然后调用synchronized方法,f2()可以顺利执行、不会被阻塞。f1()f2()互相调用,也不会发生阻塞。

  Java SE 5提供的ReentrantLocks可以被打断。

BlockedMutex在创建时就对其自己的lock进行了锁定,Blocked2blocked.f()被阻塞,t.interrupt()可以成功消除阻塞,Blocked2得以继续运行至结束。

4. Checking for an Interrupt

  当调用interrupt()时,中断只会在任务运行至会产生阻塞的操作或任务已经被阻塞时发生,如果任务中没有会产生阻塞的操作,就无法被interrupt()打断。

  在线程上调用interrupt()会为线程设置一个被打断的标志位,该标志位可以通过Thread.interrupted()来查询;调用Thread.interrupted()后,该标志位会被自动清除。

  下面的例子展示了当run()中可能不存在阻塞操作时,使用Thread.interrupted()判断是否应当打断任务的方法:

运行这个例子必须要使用命令行指定打断任务的延时,上面的Output只是给出了一种可能的情况,

需要特别注意通过异常中断任务后的收尾工作,Blocked3run()NeedsCleanup n1 = new NeedsCleanup(1)实例化n1后紧跟try-finally,并在finally中清理n1