AsynchronousFileChannel 使用的默认线程池的疑问

AIO服务在线上测试有一周时间了吧，现在发现一个问题，通过“任务管理器”查看aio服务的进程可以看出该进程的当前线程数经过几天的运行，在不断的增加：

1. 刚刚启动的时候，线程数在16个左右

2. 经过半天的运行，线程数达到30 - 50个左右

3. 经过几天的运行，线程数一般稳定在100个左右，基本上不再增加，或增加的很慢了。

我检查了一下代码，在AsynchronousServerSocketChannel中使用的是一个固定大小的线程池，所以这个地方不会导致使用的线程数不断的增加。

唯一有可能导致线程数增加的地方就是 AsynchronousFileChannel，由于这个地方使用的线程池是系统默认的，具体是什么类型的线程池，我到现在也不太清楚，我下午试了一下，换成一个固定数量的线程池，经测试发现“任务管理器”中的进程使用的线程数已可以控制在指定的范围里，但同时也发现性能下降了一些（并发数下降了一些），不管我把这个固定的线程池设置为10，还是50，还是100，性能还是上不去，算了，只好又改回原来使用系统默认的线程池吧，不再使用定制的线程池了。

我现在想的是，为什么AsynchronousFileChannel使用的默认线程池不能在系统空闲的时候回收一部分线程?如果遇到大并发的情况下，线程数可能达到500，难道以后这个aio进程就一直保持500个线程？

2012-07-09