背景

内部有个框架主要用于做最终一致性，通过分布式JOB+DB的方式来处理一些存在分布式事务，比如DB+MQ。方案的思路是运行时先往数据库落一个任务，然后异步执行任务。

通过定时任务异步的捞取任务来检查状态决定是否重试，以此达到最终一致性。

任务的处理通过线程池来控制。

排查

先看线程池的参数设置：

核心线程数 x
队列长度为 x/2
最大线程数 x + x/2
keepAliveSeconds 10h

粗略一看，感觉对于当前的任务处理没什么问题，但是其实埋藏着一些风险。

检查是否有运行阻塞的任务

通过arthas trace跟踪，得到的结果非常正常。

看线程堆栈

通过jstask 打印出线程堆栈来查看，发现所有的线程都处于阻塞，等待任务的状态。（线程是x + x/2）

java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000821ce058> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
        at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
--
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000842cf2b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

这明显跟现在的任务运行不符合，现在的任务是每次定时任务触发时，会触发x个任务，但是会有一定数量的异常，具体多少个没有细算。

下意识的假定，现在所有的线程都处于等待任务的状态，说明队列是空的，那么此时任务至少应该是x+x/2+x+x/2 的数量才会开始抛出拒绝状态。

因为这个错误的假定，耗费了非常多的时间去排查其他问题。后来反复看堆栈，才摸到了思路，源自于parking to wait for这个提示。

如果线程池是刚创建出来的，那么毫无疑问，假定是正确的，可是运行了一段时间的线程池，如果没有及时回收的话，线程会处于阻塞，等待队列任务的状态，看线程池的提交任务的代码：

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) { // 如果线程数量小于核心线程数
            if (addWorker(command, true)) // 创建工作线程，该任务为此工作线程的第一个任务执行
                return;
            c = ctl.get();
        }
        if (isRunning(c) && workQueue.offer(command)) { // 添加到队列
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        else if (!addWorker(command, false)) // 尝试创建工作线程，false表示已最大线程数来作为条件
            reject(command);
    }

所以当工作线程都存在时，任务首先要做的是入队列。队列为阻塞队列：

protected BlockingQueue<Runnable> createQueue(int queueCapacity) {
        return (BlockingQueue)(queueCapacity > 0 ? new LinkedBlockingQueue(queueCapacity) : new SynchronousQueue());
}

offer方法都有啥，核心包括入队列，还有唤醒阻塞在队列上的线程，而线程在运行时，从队列中poll任务时，需要获取锁。

意味着，不是所有的任务进去就能立刻被线程消费，而回去看队列的值queueCapacity = x/2，显而易见，每次进来x个任务，队列肯定放不下，于是就会看到每次都有一定数量的任务被拒绝。

设置队列值queueCapacity = 2x，异常已没有出现，暂定为已处理。

简单的问题也容易一叶障目。