任务执行、取消和关闭

任务Task

Task就是抽象、离散的工作单元unit。把一个应用程序的工作work分离到任务中，可简化程序的管理；这种分离还在不同事务间划分了 自然的分界线，可以方便程序出现错误时进行恢复；同时，这种分离还可以为并行工作提供一个自然的结构，有利于提高程序的并发性。

---

任务执行

围绕执行任务来管理应用程序时，首先要指明一个清晰的任务边界TaskBoundaries；其次，应用程序应该在负荷过载时平缓地劣化，而不应该负载一高就简单地失败告终，这需要一个明确的任务执行策略。

• 》顺序执行任务
  应用程序内部的任务调度，存在多种可能的调度策略，这种策略可以在不同程度上发挥出潜在的并发性。其中最简单的策略就是在单一线程中顺序地执行任务。例如：

    public class SingleThreadWebServer {
        public static void main(String[] args) throws IOException {
            ServerSocket socket = new ServerSocket(80);
            while(true) {
                //不断接收用户请求，然后进行处理请求。但是这个处理是串行、顺序化的处理过程。
                Socket connection = socket.accept();
                handleRequest(connection);  
            }
        }
    }

顺序化处理，几乎不能为服务器应用提供良好的吞吐量或快速的响应性。不过，如果任务的数量很少但生命周期很长时，或者当服务器只服务于唯一的用户时，服务器在同一时间内只需同时处理一个请求下，顺序化处理策略可能适用。

• 》每任务每线程
  每任务每线程，避免顺序化处理任务时的响应性差的问题。因为执行任务的负载已经脱离了主线程，并行处理任务，同时保证任务在线程安全的代码中执行。

public class ThreadPerTaskWebServer {
    pubilc static void main(String[] args) throws IOException {
        ServerSocket socket = new ServerSocket(80);
        while(true) {
            final Socket connection = socket.accept();
            //创建任务线程来并行的执行任务，从而提高响应性
            Runnable task = new Runnable() {
                public void run() {
                    handlerRequest(connection);
                }
            };
            new Thread(task).start();
        }
    }
}

无限创建线程的缺点：线程生命周期的开销（线程的创建与关闭是要占用内存、CPU）；资源消耗量（活动线程会消耗系统资源，尤其是内存，而服务器的内存、CPU有限）；稳定性（任务间共享数据带来数据的不一致性问题，同步代码的复杂度较高，不利于维护）。

• 》无限任务有限线程
  应用程序的计算能力有限，如果采用每任务每线程处理策略，在并发量较大时，应用程序的吞吐量和响应性都会变得很槽糕。问题的关键在于任务的提交速率和任务的处理速率间的匹配，或者类比于生产者和消费者之间匹配，寻找平衡点是高效应用程序必备条件。首先，限定创建线程Thread的数量，也就是采用线程池ThreadPool来规定应用程序的处理能力；其次，在任务处理到达ThreadPool极限时，此时若有空闲Thread资源，则进行复用（执行新任务），若没有空闲Thread，则执行一种缓存任务策略；如果ThreadPool到达极限，而缓存Task也到达极限（限定长度或者内存不够），则如何优雅的处理新到来Task。JDK对于这样的程序设计需求，提供了一个强大的处理器，即Executor执行框架。

public class TaskExecutionWebServer {
    private static int NTHREADS = 100;
    private static final Executor exec = Executors.newFixedThreadPool(NTHREADS);

    public static void main(String[] args) throws IOException {
        ServerSocket socket = new ServerSocket(80);
        while(true) {
            final Socket conn = socket.accept();
            Runnable task = new Runnable() {
                public void run() {
                    handlerRequest(conn);
                }
            };
            //将任务交给执行框架处理，此时任务框架是计算资源有限的执行器。它在任务提交和任务处理之间建立平衡，当任何一方超出了平衡范围，则调用相应的策略来维持平衡。
            exec.execute(task);
        }
    }
}

• 》依赖任务执行
  任务在线程中执行时，存在两种状况：独立边界任务、依赖其他任务的任务。当应用程序需要了解任务执行状态时，或者一个任务依赖另一任务的执行结果时，线程执行单元Runnable接口不能满足需求，因为run没有返回值和相应的异常Exception抛出。JDK1.5开始，提供了Callable、Future两个接口来标识带返回值的任务、任务状态。同时具备返回值和状态的任务类为FutureTask，但观察FutureTask发现implements Runnaable，Future两个接口，构造器包装了Runnable为Callable。例如，浏览器渲染页面，一边下载图片一边渲染到显示器中进行显示，两者有依赖关系（因为先渲染文本，然后给图像预留空间，如果下载完成了图像则渲染到页面）。

public class FutureRender {
    private static int NTHREADS = 100;
    private final static ExecutorService executor = Executors.newFixedThreadPool(NTHREADS);
    //根据页面html元素进行渲染页面
    void renderPage(CharSequence source) {
        //扫描记录页面图像控件<img>,并返回ImageInfo实例
        final List<ImageInfo> imageInfos = scanForImageInfo(source);
        Callabe<List<ImageInfo>> task = new Callabe<List<ImageInfo>>() {
            public List<ImageInfo> call() {
                List<ImageData> result = new ArrayList<ImageData>();
                //遍历出html中img进行二进制下载，这个下载过程是Socket I/O过程
                for(ImageInfo info : imageInfos) result.add(info.downLoadImage());
                return result;
            }
        };
        Future<List<ImageData>> future = executor.submit(task);
        //先渲染文本
        renderText(source);
        try {
            //获取下载的返回值，但是get是一个阻塞方法
            List<ImageData> imageDatas = future.get(); 
            //当图像资源加载完毕时，则进行渲染
            for(ImageData data : imageDatas) renderImage(data);
        } catch(Exception e) {
            //出现异常，则中断线程和取消任务
            Thread.currentThread().interrupt();
            future.cancel();
        }
    }
}

总结

围绕任务的执行来构造应用程序，可以简化开发，以便于同步。Executor框架有助于任务的提交与执行策略间进行解耦，同时还支持很多不同类型的执行策略，关键在于确定任务的边界。

---

任务取消

通常任务结束后，执行任务的线程会自行停止。但有时候，我们希望在任务或线程自然结束前就停止它们，可能用户取消了操作，或者应用程序关闭等。然而，要做到安全、快速和可靠地停止任务或线程并不容易。Java没有提供任何机制来安全地强迫线程停止工作，但它提供了一种协作机制——中断，它使得一个线程能够要求另一个线程停止当前工作。“处理好失败、关闭和取消是好的软件和勉强运行的软件的最大区别。”

• 》取消
  当外部代码能够在活动 自然完成前，把任务更改为完成状态，那么这个任务称为“可取消的任务”。取消任务的原因如下：用户请求的取消、限时活动、应用程序事件、错误和关闭等。一个可取消的任务必须拥有“取消策略”，它详细说明了取消任务的“how”、“when”和“what”——其他代码如何请求取消该任务，任务在什么时候检查取消的请求，怎么响应取消请求。
• 》中断
  线程中断是一个协作机制，一个线程给另一个线程发送信号signal，通知它在方便或可能的情况下停止正在做的工作，去做其他的事情。每一个Thread都有一个boolean类型的中断状态interrupted status，在中断的时候，这interruptedStatus被设置成true。Thread包含其他用于中断线程的方法以及获取线程中断状态的方发。

public class Thread {
    public void interrupt() { //请求中断}
    public boolean isInterrupted() {//获取中断状态}
    public static boolean interrupted() {//清除当前线程的中断状态，并返回}
}

同时，阻塞库函数，比如Thread.sleep(休眠)、Thread.join（阻塞）和Object.wait（阻塞）,试图监测线程何时被中断，并提前返回（清除中断状态，并抛出InterruptedException）。”JVM没有对阻塞方法发现中断的速度做出保证，不过一般响应速度还是比较迅速。”

public class Test {
    public static void main(String[] args) {
        Thread curThread = Thread.currentThread();
        Test test = new Test();
        try {
            // curThread.join() 1、阻塞线程发生中断
            //Thread.sleep(100) 2、线程休眠发生中断
            //test.wait()       3、线程在对象上发生中断
        } catch(InterruptedException ex) {
            //响应中断
        }
    }
}

如果线程并不在阻塞状态，此时发生中断时，JVM会设置线程的状态状态为true，然后一直等待被取消的任务获取中断状态，来检查是否发生了中断InterruptedException,如果不触发InterruptedException，中断状态会一直保持，直到有人特意去清除中断状态false。调用interrupt并不意味着必然停止目标线程正在进行的工作，它仅仅传递了请求中断的消息。
一个中断策略决定线程如何应对中断请求，即发现中断时，线程会做什么。任务不会在拥有自己的线程中执行，它们借助于服务的线程，比如线程池，在线程池中中断一个工作者线程，意味着取消当前任务，并关闭工作者线程。线程的中断策略依赖于应用程序对中断的处理规则，比如暂停或重新开始任务、进行流关闭和清理工作以及关闭应用程序等。响应中断的两种方式为：传递InterruptedException异常或保持中断状态true。

因为每一个线程都有其自己的中断策略，所以你不应该中断线程，除非调用者知道中断对这个线程意味着什么。

• 》处理不可中断的阻塞
  java.io中的同步Socket I/O，在服务器 应用程序中，阻塞I/O最常见的形式是读取和写入Socket。InputStream和OutputStream中的read和write方法都不响应中断，但是通过关闭底层的Socket，可以让它们所阻塞的线程抛出SocketException。java.nio中的同步I/O,中断一个等待InterruptibleChannel的线程，会导致抛出ClosedByInterruptException，并关闭链路。获得锁，如果一个线程在等待内部锁，那么如果不能确保它最终获得锁。
• 》停止基于线程的服务
  应用程序通常会创建拥有线程的服务，比如线程池，这些服务的存在时间通常比创建它们的方法存在的时间更长。应用程序可能拥有服务，服务可能拥有工作者线程，但是应用程序并不拥有工作者线程，因此应用程序不应该试图直接停止工作者线程。相反，服务应该提供生命周期方法来关闭它自己，并关闭它所拥有的线程，那么当应用程序关闭这个服务时，服务就可以关闭所有的线程了。ExecutorService提供了shutdown和shutdownNow方法，其他线程所持有的服务也应该 都提供了类似的关闭机制。

对于线程持有的服务，只要服务的存在时间大于创建线程的方法存在的时间，那么就应该提供生命周期方法。

//不支持关闭的生产者-消费者日志服务
public class LogService {
    private final BlockingQueue<String> queue;
    private final LoggerThread logger;
    private final PrintWriter writer;
    private boolean isShutdown;
    private int reservations;

    public void start() { logger.start(); }

    public void stop() {
        synchronized(this) {isShutdown = true;}
        logger.interrupt();
    }

    public void log(String msg) throws InterruptedException {
        synchronized(this) {
            if(isShutdown) 
                throw new IllegalStateException("... ...");
            ++reservations;
        }
        queue.put(msg);
    }  

    private class LoggerThread extends Thread {     
        public void run() {
            try {
                while(true) {
                    try {
                        synchronized(LogService.this) 
                            if(isShutdown && reservations == 0) break;
                        String msg = queue.take();
                        synchronized(LogService.this) --reservations;
                        writer.println(msg);
                    } catch(InterruptedException ex) {
                        /*重试*/
                    }        
                }
            } finally {
                writer.close();
            }
        }
    }

}

---

任务关闭

任务关闭其实应该称为服务的关闭，因为任务只有等待、运行和结束这三种状态。应用程序提供服务来执行任务，而服务包含启动、运行、关闭和终止四种状态，启动表示服务准备接受任务，运行表示服务在执行任务，关闭表示服务停止接受、执行任务，而终止表示服务生命周期结束。

• 》ExecutorService
  在Executor执行框架中的生命周期管理ExecutorService服务中，提供了两种关闭服务的方法：shutdown和shutdownNow，两种方式在安全性和响应性之间进行了权衡，shutdownNow的速度更快而风险大（任务可能没有执行完就终结了），shutdown的速度慢而安全（直到队列中所有任务完成前，服务都不会关闭）。

public class LogService {
    //通过分装Executor进行服务管理，使用Executor代理服务
    private final ExecutorService exec = Executors.newSingleThreadExecutor();
    //....
    public void start() {}

    public void stop() throws InterruptedExecption {
        try {
        //优雅的关闭，因为exec会先等待服务执行完所有已经提交的任务，阻止提交新任务，然后在关闭服务。
            exec.shutdown();
            //还可以设置等待时间，如果超时则强行关闭
            exec.awaitTermination(TIMEOUT, UNIT);
        } finally {
            writer.close();
        }
    }
    //....
}

使用shutdownNow关闭服务时，存在一定的局限性：

它试图取消正在进行的任务，并返回那些已经提交而没有执行的任务，这样调用者得不到那些已经进行了的任务。

• 》致命药丸
  另一种保证生产者和消费者服务关闭的方式是使用标记（也称为致命药丸）：用一个可识别的对象，存入工作队列中，它表示“当你得到它时，停止一切工作”，在顺序队列中，致命药丸保证了消费者完成工作队列中致命药丸对象前的所有任务，而生产者在提交了致命药丸后不能提交任务。致命药丸就像无限循坏中的break标识一样，只不过这是一个循序标识。
• 》处理异常终止的线程
  线程运行终止包含正常结束和异常退出两种情况，当线程抛出RuntimeException未检查异常时会导致线程死亡（如果没有捕获它，而Runnable不能throws任何Exception），RuntimeException异常也表明程序出现错误。当线程因为未捕获异常而退出时，JVM会把这个事情报告给应用程序提供的UncaughtExceptionHandler，如果Handler不存在，默认的行为是向System.err错误流中打印出栈追踪信息。

在JDK5.0之前，操控UncaughtExceptionHandler唯一的方法是子类化ThreadGroup。JDK5.0之后，可以通过实例方法thread.setUncaughtExceptionHanlder为每一个线程设置一个Handler，或静态方法Thread.setDefaultUncaughtExceptionHandler来设置默认的Handler。如果两个都设置了，JVM只会选择其中的一个执行，首先检查实例方法。
那么ThreadPoolExecutor如何设置UncaughtExceptionHandler，只要在构造函数中传递ThreadFactory时构建的Thread进行设置Handler就行。然后，Executor中只有通过execute提交的任务才能将它抛出的异常移交给Handler进行处理；而通过submit提交的任务、抛出的任何异常（无论是否受检查）都被认为是任务返回状态的一部分，即Future.get的一部分。

• 》JVM关闭
  JVM既可以通过正常手段关闭，也可以强行关闭。在正常关闭时，JVM首先会启动所有已注册showdown钩子的线程，如Runtime.getRuntime().addShutdownHook(Thread hook)来注册构子处理器，也可以通过removeShutdownHook(Thread hook)来取消已经注册的钩子。

---

总结

任务、线程、服务以及应用程序在生命周期结束时，可能会引入复杂的设计和实现。JDK没有具体可行的机制来终结线程，但它提供了中断机制来帮助取消正在运行的工作。使用FutureTask和Executor框架可以简化构建可取消的任务和服务，而关键在如何构建取消协议。