带持久化缓冲的ThreadPoolExecutor

    由于项目中需要使用ArrayBlockingQueue方式的ThreadPoolExecutor，设置的有界队列上限为1000，由于java默认在线程数超过maximumPoolSize时会抛弃超过上限的请求，所以在某些压力较大情况下会出现丢弃较多请求的情况。所以如果能先把超过上限的请求序列化到某种存储介质上，然后按照先进先出一批批的提供给后面的工作线程，做一个类似“阀门”装置，那就比较好了。
    目前这个组件已经开发完毕，目前开源地址是https://github.com/netcomm/sponge，它的基本介绍如下：

#使用方式跟普通的ThreadPoolExecutor没有任何差别，开发人员没有任何感觉。

#正常情况下请求都走内存，只有在超过阀值后，请求才会进行持久化，一旦持久化的请求都被消费后，重新进入内存模式。这极大的保证了性能和缓冲的平衡。

#在突发极大并发请求下，保证系统的稳定性为第一目标。

#能自动缓冲超过某个阀值的任务请求。

#缓冲持久化的方式灵活，可根据使用场景进行选择，如基于文件(系统吞吐量巨大)、数据库(系统吞吐量大)、redis(系统吞吐量巨大)、…。

#任务的请求处理顺序默认先进先出模式。

#实现原理简单，代码量少。

#默认实现基于文件的缓冲持久化模式。

#关键参数可调整。
     功能虽小，但用途还是比较广的，理论上任何使用ThreadPoolExecutor的地方，都可以用它来替代。欢迎大家在实际项目中使用，有任何问题都请联系我或提交到github上。

先mark了，这个主意很赞~
不知道持久化有两点是怎么做的：持久化以后，怎么让queue知道何时去读取持久化数据；持久化部分是不是可以扩展，比如基于文中说的几种形式，实现我自己的持久化方案
先check了代码看看~

“持久化以后，怎么让queue知道何时去读取持久化数据”，代码中可以找到答案。持久化的扩展可以参考FilePersistence这个类是如何做的，扩展其他的应该也容易。

mark

周末checkout来学习学习

它其实还可以有很多作用，比分说可以作为一个靠谱的前端请求服务分发器等等，欢迎大家提出更多有意思的使用场景。

这个要支持，项目中很多地方用到了ThreadPoolExecutor

貌似不支持
tmpThreadPool.execute(
        new Runnable(){
     @Override
     public void run() {

     }
        }
);
这种形式

周末有时间下代码来学习学习！

ThreadPoolExecutor默认的线程数是int的最大值2的32次-1,相当于20亿个线程，不可能超，如果超过线程数，而且ThreadPoolExecutor本身就有LinkedBlockingQueue来维护其线程队列.
你说的请求序列化，好像和ThreadPoolExecutor没啥关系，完全不用改jdk并发包的代码

可以再仔细看看，它的作用不是你描述的那样，hoho，源码比较简单，下下来看看就知道了。