并发编程实战学习笔记（五）——取消与关闭

布满荆棘的人生 2022-09-28 11:44 167阅读 0赞

## **题记** ##

在Java中没有一种安全的抢占方法来停止线程，因此也就没有安全的抢占式方法来停止任务。只有一些协作式的机制，使请求取消的任务和代码都遵循一种协商好的协议。

## **响应中断时执行的操作包括** ##

*  清除中断状态
 *  抛出InterrruptedException，表示阻塞操作由于中断而提前结束

## **对中断操作的正确理解** ##

调用interrupt并不意味着立即停止目标线程正在进行的工作，而只是传递了请求中断的消息。  
它并不会真正地中断一个正在运行的线程，而只是发出中断请求，然后由线程在下一合适的时刻中断自己。

## **论断** ##

*  通常，中断是实现取消的最合理方式。
 *  只有实现了线程中断策略的代码才可以屏蔽中断请求。在常规的任务和库代码中都不应该屏蔽中断请求。
 *  使用线程池往往比直接new Thread会更加方便，因为线程池封装了相关特性，如线程封装，批量中断机制等。

## **代码响应方式** ##

*  阻塞库方法，捕捉InterruptedException，做好清除工作，然后结束线程
 *  自己的代码在合适的地方判断isInterrupted(),以响应中断
 *  一些阻塞方法但不抛出InterruptedException的，需要具体讨论，参见下述

## **处理不可中断的阻塞** ##

*  Java.io包中的同步socket I/O。通过关闭底层的套接字，可以使得由于执行read或者write等方法而被阻塞的线程抛出一个SocketException。
 *  Java.io包中的同步I/O。当中断一个正在InterruptibleChannel上等待的线程时，将抛出CloseByInterruptException并关闭链路
 *  Selector的异步I/O。如果一个线程在调用Selector.select方法（java.io.channels中）时阻塞了，那么调用close或者wakeup方法会使线程抛出ClosedSelectorException并提前返回。
 *  获取一个锁。如果一个线程由于等待某个内置锁而阻塞，那么将无法响应中断。但在，在Lock类中提供了lockInterruptibly方法，该方法允许在等待一个锁时仍能响应中断。

## **区分任务与线程对中断的反应是很重要的** ##

你是中断任务还是中断线程，含义并不相同。比如在线程池里，你只是中断任务，处理完成异常，清除状态之后，只需要简单返回就行，但如果确定是要中断线程，则要进行其它考虑了。

## **响应中断** ##

当调用可中断的阻塞函数时，有两种实用策略可用于处理InterruptedException

*  传递异常（可能在执行某个特定于任务的清除操作之后），从而使得你的方法也成为可中断的阻塞方法。
 *  恢复中断状态，从而使得调用栈中的上层代码能够对其处理。  
    注意：只有实现了线程中断策略的代码才可以屏蔽中断请求。在常规的任务和库代码中都不应该屏蔽中断请求。

## **线程池中的任务通过Future来实现取消，其中CANCEL API文档说明** ##

*  返回结果：返回FALSE：任务已经取消，已经完成等不能取消的原因。否则返回true
 *  如果任务未开始执行，则不再执行
 *  如果任务已经在运行了，则取决于参数mayInterruptIfRunning，true则会被中断，false则不会中断

## **线程池shutdownnow的局限性：我们无法通过常规方法找出哪些任务已经开始但尚未结束** ##

如果我们需要知道这些任务，并且不想直接中断而是进行继续的后续处理，则可以使用TrackingExecutor找出哪些任务已经开始但还没有正常完成。在Executor结束后，getCancelledTasks返回被取消的任务清单。

public class TrackingExecutor extends AbstractExecutorService{ 
        private final ExecutorService exec;
        private final Set<Runnable> tasksCancelledAtShutdown = Collections.synchronizedSet(new HashSet<Runnable>());
        ....
        public List<Runnable> getCancelledTasks(){
            if(!exec.isTerminated()) throw new IllegalStateException(....);
            return new ArrayList<Runnable>(tasksCancelledAtShutdown);
        }
    
        public void executor(final Runnable runnable){
            //重点看这一段代码
            try{
                runnable.run();
            }finally{
                if(isShutdown() && Thread.currentThread().isInterrupted())
                   tasksCancelledAtShutdown.add(runnable);
            }
        }
        // 将ExecutorService其它方法委托给exec
    }
    
    //另一段使用TrackingExecutor类的代码
    public synchronized void stop() throws InterruptedException{
        try{
            saveUncrawled(exec.shutdownNow());
            if(exec.awaitTermination(TIMEOUT,UNIT)) 
                saveUncrawled(exec.getCancelledTasks);
        }finally{
            exec = null;
        }
    }

## **非正常的线程终止处理办法** ##

*  线程应该在try-catch块中调用这些任务，这样就能捕获那些未检查的异常了。或者也可以使用try-finally代码块来确保框架能够知道线程非正常退出的情况，并做出正确的响应。你或者会捕获RuntimeException异常，即当通过Runnable这样的抽象机制来调用未知和不可信的代码时。
 *  在Thread API中同样提供了UncaughtExceptionHandler，它能检测出某个线程由于未捕获的异常而终结的情况。  
    
    
     *  要为线程池中的所有线程设置一个UncaughtExceptionHandler,需要为ThreadPoolExecutor的构造函数提供一个ThreadFactory.
     *  令人困惑的是，只有通过execute提交的任务，才能将它抛出的异常交给未捕捉异常处理器，而通过submit提交的任务，无论是抛出的未检查异常还是已检查异常，都将被认为是任务返回状态的一部分。如果一个由submit提交的任务由于抛出了异常而结束，那么这个异常将被Future.get封装在ExecutionException中重新抛出。

## **QUESTION:主线程退出，子线程没有退出，JVM会退出吗？** ##

ANSWER:不会退出，因为只要有非daemon线程未退出，JVM就不会退出。