public interface Runnable {

    public abstract void run();
}

那么如果 run() 方法中抛出了RuntimeException，将会怎么处理了？

通常java.lang.Thread对象运行设置一个默认的异常处理方法：

java.lang.Thread.setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler)

而这个默认的静态全局的异常捕获方法时输出堆栈。

当然，我们可以覆盖此默认实现，只需要一个自定义的java.lang.Thread.UncaughtExceptionHandler接口实现即可。

public interface UncaughtExceptionHandler {

    void uncaughtException(Thread t, Throwable e);
}

而在线程池中却比较特殊。默认情况下，线程池 java.util.concurrent.ThreadPoolExecutor 会Catch住所有异常， 当任务执行完成(java.util.concurrent.ExecutorService.submit(Callable))获取其结果 时(java.util.concurrent.Future.get())会抛出此RuntimeException。

/**
 * Waits if necessary for the computation to complete, and then
 * retrieves its result.
 *
 * @return the computed result
 * @throws CancellationException if the computation was cancelled
 * @throws ExecutionException if the computation threw an exception
 * @throws InterruptedException if the current thread was interrupted while waiting
 */
V get() throws InterruptedException, ExecutionException;

其中 ExecutionException 异常即是java.lang.Runnable 或者 java.util.concurrent.Callable 抛出的异常。

也就是说，线程池在执行任务时捕获了所有异常，并将此异常加入结果中。这样一来线程池中的所有线程都将无法捕获到抛出的异常。 从而无法通过设置线程的默认捕获方法拦截的错误异常。

也不同通过自定义线程来完成异常的拦截。

好在java.util.concurrent.ThreadPoolExecutor 预留了一个方法，运行在任务执行完毕进行扩展（当然也预留一个protected方法beforeExecute(Thread t, Runnable r)）：

protected void afterExecute(Runnable r, Throwable t) { } 

此方法的默认实现为空，这样我们就可以通过继承或者覆盖ThreadPoolExecutor 来达到自定义的错误处理。

解决办法如下：

ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(11, 100, 1, TimeUnit.MINUTES, //
        new ArrayBlockingQueue<Runnable>(10000),//
        new DefaultThreadFactory()) {

    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        printException(r, t);
    }
};

private static void printException(Runnable r, Throwable t) {
    if (t == null && r instanceof Future<?>) {
        try {
            Future<?> future = (Future<?>) r;
            if (future.isDone())
                future.get();
        } catch (CancellationException ce) {
            t = ce;
        } catch (ExecutionException ee) {
            t = ee.getCause();
        } catch (InterruptedException ie) {
            Thread.currentThread().interrupt(); // ignore/reset
        }
    }
    if (t != null)
        log.error(t.getMessage(), t);
}

此办法的关键在于，事实上 afterExecute 并不会总是抛出异常 Throwable t，通过查看源码得知，异常是封装在此时的Future对象中的， 而此Future对象其实是一个java.util.concurrent.FutureTask的实现，默认的run方法其实调用的 java.util.concurrent.FutureTask.Sync.innerRun()。

这里我们可以看到它吃掉了异常，将异常存储在java.util.concurrent.FutureTask.Sync的exception字段中：

/** The exception to throw from get() */
private Throwable exception;

当我们获取异步执行的结果时， java.util.concurrent.FutureTask.get()

public V get() throws InterruptedException, ExecutionException {
    return sync.innerGet();
}

java.util.concurrent.FutureTask.Sync.innerGet()

V innerGet() throws InterruptedException, ExecutionException {
    acquireSharedInterruptibly(0);
    if (getState() == CANCELLED)
        throw new CancellationException();
    if (exception != null)
        throw new ExecutionException(exception);
    return result;
}

异常就会被包装成ExecutionException异常抛出。

也就是说当我们想线程池 ThreadPoolExecutor(java.util.concurrent.ExecutorService)提交任务时， 如果不理会任务结果（Feture.get()），那么此异常将被线程池吃掉。

<T> Future<T> submit(Callable<T> task);
Future<?> submit(Runnable task);

而java.util.concurrent.ScheduledThreadPoolExecutor是继承ThreadPoolExecutor的，因此情况类似。

结论，通过覆盖ThreadPoolExecutor.afterExecute 方法，我们才能捕获到任务的异常（RuntimeException）。

原文地址：http://imxylz.com/blog/2013/08/02/handling-the-uncaught-exception-of-java-thread-pool/

使用线程的一种说法是为了提高性能。多线程可以使程序充分利用闲置的资源，提高资源的利用率，同时能够并行处理任务，提高系统的响应性。 但是很显然，引入线程的同时也引入了系统的复杂性。另外系统的性能并不是总是随着线程数的增加而总是提高。

性能与伸缩性

性能的提升通常意味着可以用更少的资源做更多的事情。这里资源是包括我们常说的CPU周期、内存、网络带宽、磁盘IO、数据库、WEB服务等等。 引入多线程可以充分利用多核的优势，充分利用IO阻塞带来的延迟，也可以降低网络开销带来的影响，从而提高单位时间内的响应效率。

为了提高性能，需要有效的利用我们现有的处理资源，同时也要开拓新的可用资源。例如，对于CPU而言，理想状况下希望CPU能够满负荷工作。当然这里满负荷工作是指做有用的事情，而不是无谓的死循环或者等待。受限于CPU的计算能力，如果CPU达到了极限，那么很显然我们充分利用了计算能力。对于IO而言（内存、磁盘、网络等），如果达到了其对于的带宽，这些资源的利用率也就上去了。理想状况下所有资源的能力都被用完了，那么这个系统的性能达到了最大值。

为了衡量系统的性能，有一些指标用于定性、定量的分析。例如服务时间、等待时间、吞吐量、效率、可伸缩性、生成量等等。服务时间、等待时间等用于衡量系统的效率，即到底有多快。吞吐量、生成量等用于衡量系统的容量，即能够处理多少数据。除此之外，有效服务时间、中断时间等用于能力系统的可靠性和稳定性等。

可伸缩性的意思是指增加计算资源，吞吐量和生产量相应得到的改进。 从算法的角度讲，通常用复杂度来衡量其对应的性能。例如时间复杂度、空间复杂度等。

Amdahl定律

并行的任务增加资源显然能够提高性能，但是如果是串行的任务，增加资源并不一定能够得到合理的性能提升。 Amdahl定律描述的在一个系统中，增加处理器资源对系统行的提升比率。 假定在一个系统中，F是必须串行化执行的比重，N是处理器资源，那么随着N的增加最多增加的加速比：

理论上，当N趋近于无穷大时，加速比最大值无限趋近于1/F。 这意味着如果一个程序的串行化比重为50%，那么并行化后最大加速比为2倍。

加速比除了可以用于加速的比率外，也可以用于衡量CPU资源的利用率。如果每一个CPU的资源利用率为100%，那么CPU的资源每次翻倍时，加速比也应该翻倍。 事实上，在拥有10个处理器的系统中，程序如果有10%是串行化的，那么最多可以加速1/(0.1+(1-0.1)/10)=5.3倍，换句话说CPU的利用率只用5.3/10=53%。而如果处理器增加到100倍，那么加速比为9.2倍，也就是说CPU的利用率只有个9.3%。

显然增加CPU的数量并不能提高CPU的利用率。下图描述的是随着CPU的数量增加，不同串行化比重的系统的加速比。

很显然，串行比重越大，增加CPU资源的效果越不明显。

性能提升

性能的提升可以从以下几个方面入手。

系统平台的资源利用率

一个程序对系统平台的资源利用率是指某一个设备繁忙且服务于此程序的时间占所有时间的比率。从物理学的角度讲类似于有用功的比率。简单的说就是：资源利用率=有效繁忙时间/总耗费时间。

也就说尽可能的让设备做有用的功，同时榨取其最大值。无用的循环可能会导致CPU 100%的使用率，但不一定是有效的工作。有效性通常难以衡量，通常只能以主观来评估，或者通过被优化的程序的行为来判断是否提高了有效性。

延迟

延迟描述的是完成任务所耗费的时间。延迟有时候也成为响应时间。如果有多个并行的操作，那么延迟取决于耗费时间最大的任务。

多处理

多处理是指在单一系统上同时执行多个进程或者多个程序的能力。多处理能力的好处是可以提高吞吐量。多处理可以有效利用多核CPU的资源。

多线程

多线程描述的是同一个地址空间内同时执行多个线程的过程。这些线程都有不同的执行路径和不同的栈结构。我们说的并发性更多的是指针对线程。

并发性

同时执行多个程序或者任务称之为并发。单程序内的多任务处理或者多程序间的多任务处理都认为是并发。

吞吐量

吞吐量衡量系统在单位之间内可以完成的工作总量。对于硬件系统而言，吞吐量是物理介质的上限。在没有达到物理介质之前，提高系统的吞吐量也可以大幅度改进性能。同时吞吐量也是衡量性能的一个指标。

瓶颈

程序运行过程中性能最差的地方。通常而言，串行的IO、磁盘IO、内存单元分配、网络IO等都可能造成瓶颈。某些使用太频繁的算法也有可能成为瓶颈。

可扩展性

这里的可扩展性主要是指程序或系统通过增加可使用的资源而增加性能的能力。

线程开销

假设引入的多线程都用于计算，那么性能一定会有很大的提升么？ 其实引入多线程以后也会引入更多的开销。

切换上下文

如果可运行的线程数大于CPU的内核数，那么OS会根据一定的调度算法，强行切换正在运行的线程，从而使其它线程能够使用CPU周期。

切换线程会导致上下文切换。线程的调度会导致CPU需要在操作系统和进程间花费更多的时间片段，这样真正执行应用程序的时间就减少了。另外上下文切换也会导致缓存的频繁进出，对于一个刚被切换的线程来说，可能由于高速缓冲中没有数据而变得更慢，从而导致更多的IO开销。

内存同步

不同线程间要进行数据同步，synchronized以及volatile提供的可见性都会导致缓存失效。线程栈之间的数据要和主存进行同步，这些同步有一些小小的开销。如果线程间同时要进行数据同步，那么这些同步的线程可能都会受阻。

阻塞

当发生锁竞争时，失败的线程会导致阻塞。通常阻塞的线程可能在JVM内部进行自旋等待，或者被操作系统挂起。自旋等待可能会导致更多的CPU切片浪费，而操作系统挂起则会导致更多的上下文切换。

了解了性能的提升的几个方面，也了解性能的开销后，应用程序就要根据实际的场景进行取舍和评估。没有一劳永逸的优化方案，不断的进行小范围改进和调整是提高性能的有效手段。当前一些大的架构调整也会导致较大的性能的提升。

简单的原则是在保证逻辑正确的情况小，找到性能瓶颈，小步改进和优化。

参考资料

• Amdahl's law: http://en.wikipedia.org/wiki/Amdahl%27s_law
• Gustafson's law: http://en.wikipedia.org/wiki/Gustafson%27s_law
• Sun-Ni law: http://en.wikipedia.org/wiki/Sun-Ni_law
• 多核系统中三种典型锁竞争的加速比分析 http://blog.csdn.net/drzhouweiming/article/details/1800319
• 阿姆达尔定律和Gustafson定律的等价性 http://book.51cto.com/art/201004/197506.htm

volatile

volatile只能强调数据的可见性，并不能保证原子操作和线程安全，因此volatile不是万能的。参考指令重排序

volatile最常见于下面两种场景。

a. 循环检测机制

volatile boolean done = false;


    while( ! done ){
        dosomething();
    }

b. 单例模型 （http://www.blogjava.net/xylz/archive/2009/12/18/306622.html）

synchronized/Lock

看起来Lock有更好的性能以及更灵活的控制，是否完全可以替换synchronized？

在锁的一些其它问题中说过，synchronized的性能随着JDK版本的升级会越来越高，而Lock优化的空间受限于CPU的性能，很有限。另外JDK内部的工具（线程转储）对synchronized是有一些支持的（方便发现死锁等），而对Lock是没有任何支持的。

也就说简单的逻辑使用synchronized完全没有问题，随着机器的性能的提高，这点开销是可以忽略的。而且从代码结构上讲是更简单的。简单就是美。

对于复杂的逻辑，如果涉及到读写锁、条件变量、更高的吞吐量以及更灵活、动态的用法，那么就可以考虑使用Lock。当然这里尤其需要注意Lock的正确用法。

Lock lock = 
lock.lock();
try{
    //do something
}finally{
    lock.unlock();
}

一定要将Lock的释放放入finally块中，否则一旦发生异常或者逻辑跳转，很有可能会导致锁没有释放，从而发生死锁。而且这种死锁是难以排查的。

如果需要synchronized无法做到的尝试锁机制，或者说担心发生死锁无法自恢复，那么使用tryLock()是一个比较明智的选择的。

Lock lock = 
if(lock.tryLock()){
    try{
        //do something
    }finally{
        lock.unlock();
    }
}

甚至可以使用获取锁一段时间内超时的机制Lock.tryLock(long,TimeUnit)。 锁的使用可以参考前面文章的描述和建议。

锁的边界

一个流行的错误是这样的。

看起来很合理的，对于一个线程安全的Map实现，要存取一个不重复的结果，先检测是否存在然后加入。 其实我们知道两个原子操作和在一起的指令序列不代表就是线程安全的。 割裂的多个原子操作放在一起在多线程的情况下就有可能发生错误。

实际上ConcurrentMap提供了putIfAbsent(K, V)的“原子操作”机制，这等价于下面的逻辑：

除了putIfAbsent还有replace(K, V)以及replace(K, V, V)两种机制来完成组合的操作。

提到Map，这里有一篇谈HashMap读写并发的问题。

构造函数启动线程

下面的实例是在构造函数中启动一个线程。

这里可能存在的陷阱是如果此类被继承，那么启动的线程可能无法正确读取子类的初始化操作。

因此一个简单的原则是，禁止在构造函数中启动线程，可以考虑但是提供一个方法来启动线程。如果非要这么做，最好将类设置为final，禁止继承。

丢失通知的问题

这篇文章里面提到过notify丢失通知的问题。

对于wait/notify/notifyAll以及await/singal/singalAll，如果不确定到底是否能够正确的收到消息，担心丢失通知，简单一点就是总是通知所有。

如果担心只收到一次消息，使用循环一直监听是不错的选择。

非常主用性能的系统，可能就需要区分到底是通知单个还是通知所有的挂起者。

线程数

并不是线程数越多越好，在下一篇文章里面会具体了解下性能和可伸缩性。 简单的说，线程数多少没有一个固定的结论，受限于CPU的内核数，IO的性能以及依赖的服务等等。因此选择一个合适的线程数有助于提高吞吐量。

对于CPU密集型应用，线程数和CPU的内核数一致有助于提高吞吐量，所有CPU都很繁忙，效率就很高。 对于IO密集型应用，线程数受限于IO的性能，某些时候单线程可能比多线程效率更高。但通常情况下适当提高线程数，有利于提高网络IO的效率，因为我们总是认为网络IO的效率比较低。

对于线程池而言，选择合适的线程数以及任务队列是提高线程池效率的手段。

对于线程池来说，如果任务总是有积压，那么可以适当提高corePoolSize大小；如果机器负载较低，那么可以适当提高maximumPoolSize的大小；任务队列不长的情况下减小keepAliveTime的时间有助于降低负载；另外任务队列的长度以及任务队列的拒绝策略也会对任务的处理有一些影响。

例如在Future接口中有如下一个API：

在前面的章节中描述了Future类的具体实现原理。这里不再讨论，但是比较好奇的抛出的三个异常。

这里有一篇文章（Java 理论与实践: 处理 InterruptedException）描述了InterruptedException的来源和处理方式。简单的说就是线程在执行的过程中被自己或者别人中断了。这时候为了响应中断就需要处理当前的异常。

对于java.lang.Thread而言，InterruptedException也是一个很诡异的问题。

中断一个线程Thread.interrupt()时会触发下面一种情况：

如果线程在调用 Object 类的 wait()、wait(long) 或 wait(long, int) 方法，或者该类的 join()、join(long)、join(long, int)、sleep(long) 或 sleep(long, int) 方法过程中受阻，则其中断状态将被清除，它还将收到一个 InterruptedException。

检测一个线程的中断状态描述是这样的Thread.interrupted()：

测试当前线程是否已经中断。线程的中断状态 由该方法清除。换句话说，如果连续两次调用该方法，则第二次调用将返回 false（在第一次调用已清除了其中断状态之后，且第二次调用检验完中断状态前，当前线程再次中断的情况除外）。 

也就是说如果检测到一个线程已经被中断了，那么线程的使用方（挂起、等待或者正在执行）都将应该得到一个中断异常，同时将会清除异常中断状态。

上面获取任务结果的方法实现中，将在获取锁的过程中得到一个中断异常。代码java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(int, long)描述了这种情况：

这里在获取锁的时候检测线程中断情况，如果被中断则清除中断位，同时抛出一个中断异常。为什么如此做？因为我们的线程在线程池中是被重复执行的，所以一旦线程被中断后并不会退出线程，而是设置中断位，等候任务队列自己处理线程，从而达到线程被重复利用的目的。有兴趣的可以参考代码java.util.concurrent.ThreadPoolExecutor.Worker.runTask(Runnable)。这里在关闭线程池时就会导致中断所有线程。

除了InterruptedException 异常我们还发现了一个全新的异常java.util.concurrent.TimeoutException，此异常是用来描述任务执行时间超过了期望等待时间，也许是一直没有获取到锁，也许是还没有执行完成。

在innerGet代码片段中我们看到，如果线程在指定的时间无法获取到锁，那么就会得到一个超时异常。这个很好理解，比如如果执行一个非常耗时的网络任务，我们不希望任务一直等待从而占用大量的资源，可能在一定时间后就会希望取消此操作。此时超时异常很好的描述了这种需求。

与此同时，如果取消了一个任务，那么再次从任务中获取执行结果，那么将会得到一个任务被取消的异常java.util.concurrent.CancellationException。

除了上述异常外，还将得到一个java.util.concurrent.ExecutionException异常，

这是因为我们的提交的任务java.util.concurrent.Callable在call()方法中允许抛出任何异常，另外常规的线程执行也可能抛出一个RuntimeException，所以这里简单包装了下所有异常，当作执行过程中发生的异常ExecutionException抛出。

以上就是整个异常体系，所有并发操作的异常都可以归结于上述几类。

很多情况下处理时间长度都是用java.util.concurrent.TimeUnit，这是一个枚举类型，用来描述时间长度。其中内置了一些长度的单位。其中包括纳秒、微秒、毫秒、秒、分、时、天。例如超时操作5秒，可以使用

Future.get(5,TimeUnit.SECONDS) 或者 Future.get(5000L,TimeUnit.MILLISECONDS)

当然一种单位的时间转换成另一种单位的时间也是非常方便的。另外还有线程的sleep/join以及对象的wait操作的便捷操作。

1. J.U.C 整体认识
2. 原子操作 part 1 从AtomicInteger开始
3. 原子操作 part 2 数组、引用的原子操作
4. 原子操作 part 3 指令重排序与happens-before法则
5. 原子操作 part 4 CAS操作
6. 锁机制 part 1 Lock与ReentrantLock
7. 锁机制 part 2 AQS
8. 锁机制 part 3 加锁的原理 (Lock.lock)
9. 锁机制 part 4 锁释放与条件变量 (Lock.unlock And Condition)
10. 锁机制 part 5 闭锁 (CountDownLatch)
11. 锁机制 part 6 CyclicBarrier
12. 锁机制 part 7 信号量 (Semaphore)
13. 锁机制 part 8 读写锁 (ReentrantReadWriteLock) (1)
14. 锁机制 part 9 读写锁 (ReentrantReadWriteLock) (2)
15. 锁机制 part 10 锁的一些其它问题
16. 并发容器 part 1 ConcurrentMap (1)
17. 并发容器 part 2 ConcurrentMap (2)
18. 并发容器 part 3 ConcurrentMap (3)
19. 并发容器 part 4 并发队列与Queue简介
20. 并发容器 part 5 ConcurrentLinkedQueue
21. 并发容器 part 6 可阻塞的BlockingQueue (1)
22. 并发容器 part 7 可阻塞的BlockingQueue (2)
23. 并发容器 part 8 可阻塞的BlockingQueue (3)
24. 并发容器 part 9 双向队列集合 Deque
25. 并发容器 part 10 双向并发阻塞队列 BlockingDeque
26. 并发容器 part 11 Exchanger
27. 并发容器 part 12 线程安全的List/Set CopyOnWriteArrayList/CopyOnWriteArraySet
28. 线程池 part 1 简介
29. 线程池 part 2 Executor 以及Executors
30. 线程池 part 3 Executor 生命周期
31. 线程池 part 4 线程池任务拒绝策略
32. 线程池 part 5 周期性任务调度
33. 线程池 part 6 线程池的实现及原理 (1)
34. 线程池 part 7 线程池的实现及原理 (2)
35. 线程池 part 8 线程池的实现及原理 (3)
36. 线程池 part 9 并发操作异常体系
37. 并发总结 part 1 死锁与活跃度
38. 并发总结 part 2 常见的并发场景
39. 并发总结 part 3 常见的并发陷阱
40. 并发总结 part 4  性能与伸缩性
41. 捕获Java线程池执行任务抛出的异常