newFixedThreadPool与newSingleThreadPool的区别
问题引出
newFixedThreadPool与newSingleThreadPool是jdk5之后，java.util.concurrent包下Executors类中的两个方法。前者是用于创建一个固定线程数量的线程池，后者是创建一个有且仅有一个线程的线程池。
机智的同学想必已经看出一个问题了，一个线程不也就是固定数量的一个特例吗，为什么还需要单独添加一个方法呢？
第一层
二话不说，先摆上源码。
newFixedThreadPool在jdk8中的代码如图：
newSingleThreadPool在jdk8中的代码如图：
通过肉眼粗略的比较，发现FixPool中corePoolSize和maximumPoolSize传入的都是nThreads，而SinglePool中传入的都是1。
这时有的人就悟了，这不就相当于是方法的重载嘛。一个是需要传入nThreads，而另一个就是不用传参，默认传入1。另外为了使用时更方便些，把不传参的这个方法给重命名了，变成更具象化的名称newSingleThreadPool。在我看来，这也许也是设计者Doug Lea的其中之一个目的吧。
如果你也已经看出这一点了，那么恭喜你，你已经来到了第一层。
第二层
再把源码拿出来，重新再找找不同。这是一个找茬的游戏。
其实很多小伙伴在最开始的时候就已经发现了，我们眼睛又不瞎，明显行数不一样，在newSingleThreadPool方法体的第一行，那么一大串的return new FinalizableDelegatedExecutorService早就看到了，还以为我们看不见吗？？
巧了不是，我第一次看源码的时候，就会装作看不见。毕竟在阅读源码的时候，一个我认为比较正确的思路是只看主干，忽略掉旁枝末节，只有在确实要对某一个模块去做深入的时候，才会去了解内部的细节。不然一个比较大的框架源码有几万几十万几百万行代码，哪里能啃的动。
如果你想一次性直接一行行代码读下去，把整个框架学习一遍，那我估计你肯定一个框架都读不好，是个普通人真的没有这种定力。
举个例子，一个刚开始学认字的小朋友，说‘我不认识字呀怎么办？’，‘不识字查字典呀’，‘懂了，我这就从新华字典第一页翻起，字字句句读到最后一页’。那么这个小朋友最终是读完字段后，学会认字了吗，还是永远都在读第一页了解[ā][á][ǎ][à]。
如果你能够学会怎么什么时候该去粗读，什么时候该去精读，那么恭喜你，已经到达了第二层。
至此，我就可以继续往下说了，也怕误人子弟。让看了我的文章的人，以后读源码时钻牛角尖，一个劲的要看到native方法才罢休。
第三层
再翻回来细读。作为一个正常人，直接将nThreads改写为1不就完事了吗，为什么还要去用FinalizableDelegatedExecutorService来封装一遍？凡事反常必有妖，看看jdk大佬到底为何要做此封装。
上类关系图。
其实在源码里面直接类，查看类的父类和实现的接口也很方便，不过为了在文章中能够说清楚，还是摆出关系图更直观些，也能省一些笔墨。
FinalizableDelegatedExecutorService的父类是DelegatedExecutorService,两者虽然都是Executors的内部类，DelegatedExecutorService和ThreadPoolExecutor一样，都是继承自AbstractExecutorService。说白了他们两是兄弟关系。
再看一样AbstractExecutorService中实现的方法，只有一些提交任务之类的方法。而熟悉ThreadPoolExecutor的朋友都知道，内部是有比较丰富的方法去操作线程池的核心参数的。
回头再看看DelegatedExecutorService中，竟然只实现了任务提交、关闭等方法。
两者比较之下，最终就可以发现，对于FinalizableDelegatedExecutorService来说，关闭了对线程池参数的修改权限，因此在使用中，不会将固定的线程数1误修改为非1的情况。防止出现明明设置了单个线程，在使用时却出现了线程池中存在多个线程的问题。
demo如下：
至此，能够看懂如此设计是为什么，能实现什么功能。那么已经到达了第三层。
第四层
看懂了为什么这么做，这只是术，还更应该了解法。
关于‘道、法、术、器、势’的内容可以看我其他的笔记。
法即法则、思想。了解为什么这样设计，依据的设计思想是什么？学会这些才能带你进入更深的层次。
在我浅显的看来，newSingleThreadPool的设计是一个典型的体现了单一职责原则和接口隔离原则。
此方法只能提供创建固定线程池的作用，职责单一。
对于线程核心参数不操作的情况，通过面向对象的设计，将这些方法都隔离出去，没有操作的权限。因此也体现了接口隔离的原则。
除了设计原则，在阿里的开发规范中，是禁止我们使用Executors类去直接创建线程的。
因为在最开始的构造方法中我们就已经发现，使用的队列是一个没有指定大小的无界队列，在极端情况下会出现oom。
所以说了这么久newSingleThreadPool的优点，在实际的使用场景中，并用不到这里的方法。然而我们在实际工作场景中，多多少少在特定的业务场景下，要用到单线程的线程池。
工作中如果直接使用new ThreadPoolExecutor()的方式去创建线程池时，应该完善文档，提示不要去修改线程数量。
更合理的方式应该是在第四层法的指导下，通过一些技术手段，模仿Executors这个类，实现一个器即工具类，通过代码的手段直接从根本上规避单线程池被修改线程数量而导致的问题。
如果也看懂了设计思想，也能够让这种思想指导以后的工作，那么说明你的学习是有用的，不再是那种自己感动自己的行为。此刻，你已经到达了第四层。
第五层
还没到第五层，只能等大神们帮忙盖楼搭梯，看看有没有人能领我去第五层瞧瞧高处的风景。