作为一名web工程师都希望自己做的web应用能被越来越多的人使用，如果我们所做的web应用随着用户的增多而宕机了，那么越来越多的人就会变得越来越少了，为了让我们的web应用能有更多人使用，我们就得提升web应用服务端的并发能力。那么我们如何做到这点了，根据现有的并发技术我们会有如下选择：
第一个做法：为每个客户端发送给服务端的请求都开启一个线程，等请求处理完毕后该线程就被销毁掉，这种做法很直观，但是在现代的web服务器里这种做法已经很少使用了，原因是新建一个线程，销毁一个线程的开销(开销是指占用计算机系统资源例如：cpu、内存等)是很大的，它时常会大于实际处理请求本身的开销，因此这种方式不能充分利用计算机资源，提升并发的效率是有效的，要是还碰到线程安全的问题，使用到线程的锁机制，数据同步技术，并发提升就会受到更大的限制；除此之外，来一个请求就开启一个线程，对线程数量没有任何控制，这就会很容易导致计算机资源被用尽，对于web服务端的稳定性产生很大的威胁。
第二个做法：鉴于上面的问题，我们就产生了第二种提高服务端并发量的方法，首先我们不再是一个客户端请求过来就开启一个新线程，请求处理完毕就销毁线程，而是使用线程池技术。
线程池技术就是事先创建一批线程，这批线程被放入到一个池子里，在没有请求到达服务端时候，这些线程都是处于待命状态，当请求到达时候，程序会从线程池里取出一个线程，这个线程处理到达的请求，请求处理完毕，该线程不会被销毁，而是被线程池回收，这种方式使用线程我们降低了随意创建线程和销毁线程所导致系统开销，同时也控制了服务端线程的数量，一般一个线程对应一个请求，也就控制了并发请求的个数，该方案比第一种方案提升了系统的稳定性(控制并发数量，防止并发过多导致服务程序宕机)，同时也提升了并发的数量(原因是减少了创建线程和销毁线程的开销，更充分的利用了计算机的系统资源)。
但是做法二也是有很大的问题的，具体如下：
做法二和做法一相比，做法二要好多了，但是这只是和做法一比，如果按照我们设计的目标，做法二并非完美，原因如下：首先做法二会让很多技术不扎实人认为线程池开启多少线程就决定了系统并发的数量，因此出于让系统能处理更多请求以及充分利用计算机资源的考虑，有些人会一开始就把线程池里新建线程的个数设置为最大，一个web应用的并发量在一定时间里都是一个曲线形式，峰值在一定时间范围内都是少数情况，因此一开始就开启最大线程数，自然在大多数时间内都是在浪费系统资源，如果这些被浪费被闲置的计算资源能用来处理请求，或许这些请求处理的效率会更高。此外，一个服务器到底预先开启多少个线程，这个标准很难把控，还有就是不管你用线程池技术还是新建线程的方式，处理请求的数量和线程数量数量是一一对应的关系，如果有一个时间点过来的请求数量正好超出了线程池里线程数量，例如就多了一个，那么这个请求因为找不到对应线程很有可能会被程序所遗弃掉，其实这多的一个请求并没有超出计算机所能承受的负载，而是因为我们程序设计不合理才被遗弃的，这肯定是开发人员所不愿意发生的事情。
针对这些问题在java的JDK里提供的线程池做了很好的解决(线程池技术是博大精深的，如果我们没有研究透池技术，还是不要自己去写个而是用现成的)，jdk里的线程池对线程池大小的设定使用两个参数，一个是核心线程个数，一个是最大线程个数，核心线程在系统启动时候就会被创建，如果用户请求没有超过核心线程处理能力，那么线程池不会再创建新线程，如果核心线程个数已经处理不过来了，线程池就会开启新线程，新线程第一次创建后，使用完毕后也不是立即对其销毁，也是被会收到线程池里，当线程池里的线程总数超过了最大线程个数，线程池将不会再创建新线程，这种做法让线程数量根据实际请求的情况进行调整，这样既达到了充分利用计算机资源的目的，同时也避免了系统资源的浪费，jdk的线程池还有个超时时间，当超出核心线程的线程在一定时间内一直未被使用，那么这些线程将会被销毁，资源就会被释放，这样就让线程池的线程的数量总是处在一个合理的范围里；如果请求实在太多了，线程池里的线程暂时处理不过来了，jdk的线程池还提供一个队列机制，让这些请求排队等待，当某个线程处理完毕，该线程又会从这个队列里取出一个请求进行处理，这样就避免请求的丢失，jdk的线程池对队列的管理有很多策略，有兴趣的童鞋可以问问度娘，这里我还要说的是jdk线程池的安全策略做的很好，如果队列的容量超出了计算机的处理能力，队列会抛弃无法处理的请求，这个也叫做线程池的拒绝策略。
看我这么详细的描述做法二，是不是做法二就是一个完美的方案了？答案当然是否定了，做法二并非最高效的方案，做法二也没有充分利用好计算机的系统资源。
我这里还有做法三，其具体做法如下：
首先我要提出一个问题，并发处理一个任务和单线程的处理同样一个任务，那种方式的效率更高？也许有很多人会认为当然是并发处理任务效率更高了，两个人做一件事情总比一个人要厉害吧，这个问题的答案是要看场景的，在单核时代，单线程处理一个任务的效率往往会比并发方式效率更高。
为什么呢？因为多线程在单核即单个cpu上运算，cpu并不是也可以并发处理的，cpu每次都只能处理一个计算任务，因此并发任务对于cpu而言就有线程的上下文切换操作，而这种线程上下文的开销是比较大的，因此单核上处理并发请求不一定会比单线程更有效率，但是如果到了多核的计算机，并发任务平均分配给每一个cpu，那么并发处理的效率就会比单线程处理要高很多，因为此时可以避免线程上下文的切换。
对于一个网络请求的处理，是由两个不同类型的操作共同完成，这两个操作是CPU的计算操作和IO操作，如果我们以处理效率角度来评判这两个操作，CPU操作效率是光速的，而IO操作就不尽然了，计算机里的IO操作就是对存储数据介质的操作，计算机里有如下几个介质可以存储数据，它们分别是：CPU的一级缓存、二级缓存、内存、硬盘和网络，一级缓存存储和读取数据的能力接近光速，它比二级缓存快个5倍到6倍，但是不管是一级缓存还是二级缓存，它们存储数据量太少了，做不了什么大事情，下面就是内存了，以一级缓存的效率做参照，一级缓存比内存速度快100多倍，到了硬盘存储和读取数据效率就更慢了，一级缓存比硬盘要快1000多万倍，到了网络就慢的更不像话了，一级缓存比网络要快一亿多倍，可见一个请求处理的效率瓶颈都是由IO引起的，而CPU虽然处理很快但是CPU对任务的计算都是一个接着一个处理，假如一个请求首先要等待网络数据的处理在进行CPU运算，那么必然就拖慢了CPU的处理的整体效率，这一慢就是上亿倍了，但是现实中一个网络请求处理就是由这两个操作组合而成的。对于IO操作在java里有两种方式，一种方式叫做阻塞的IO，一种方式叫做非阻塞的IO，阻塞的IO就是在做IO操作时候，CPU要等待IO操作，这就造成了CPU计算资源的浪费，浪费的程度上文里已经写到了，是很可怕的，因此我们就想当一个请求一个线程做IO操作时候，CPU不用等待它而是接着处理其他的线程和请求，这种做法效率必然很高，这时候非阻塞IO就登场了，非阻塞IO可以在线程进行IO操作时候让CPU去处理别的线程，那么非阻塞IO怎么做到这一点的呢？非阻塞IO操作在请求和cpu计算之间添加了一个中间层，请求先发到这个中间层，中间层获取了请求后就直接通知请求发送者，请求接收到了，注意这个时候中间层啥都没干，只是接收了请求，真正的计算任务还没开始哦，这个时候中间层如果要CPU处理那么就让cpu处理，如果计算过程到了要进行IO操作，中间层就告诉cpu不用等我了，中间层就让请求做IO操作，CPU这时候可以处理别的请求，等IO操作做完了，中间层再把任务交给CPU去处理，处理完成后，中间层将处理结果再发送给客户端，这种方式就可以充分利用CPU的计算机资源，有了非阻塞IO其实使用单线程也可以开发多线程任务，甚至这个单线程的处理效率可能比多线程更高，因为它没有线程创建销毁的开销，也没有线程上下文切换的开销。其实实现一个非阻塞的请求是个大课题，里面使用到了很多先进和复杂的技术例如：回调函数和轮询等，对于非阻塞的开发我目前掌握的还不够好，等我有天完全掌握了它我一定会再写一篇文章，不过这里要提到的是像java里netty技术，nginx，php的并发处理都用到这种机制的原理，特别是现在很火的nodejs它产生的原因就是依靠这种非阻塞的技术来编写更高效的web服务器，可以说nodejs把这种技术用到了极致，不过这里要纠正下，非阻塞是针对IO操作的技术，对于nodejs，netty的实现机制有更好的术语描述就是事件驱动(其实就是使用回调函数，观察者模式实现的)以及异步的IO技术(就是非阻塞的IO技术)。现在我们回到做法三的描述，做法三的核心思想就是让每个线程资源利用率更加有效，做法三是建立在做法二的基础上，使用事件驱动的开发思想，采用非阻塞的IO编程模式，当客户端多个请求发到服务端，服务端可以只用一个线程对这些请求进行处理，利用IO操作的性能瓶颈，充分利用CPU的计算能力，这样就达到一个线程处理多个请求的效率并不比多线程差，甚至还高，同时单线程处理能力的增强也会导致整个web服务并发性能的提升。大家可以想想，按这种方式在一个多核服务器下，假如这个服务器有8个内核，每个内核开启一个线程，这8个线程也许就能承载数千并发量，同时也充分利用每个CPU计算能力，如果我们开启线程越多(当然新增的线程数最好是8的倍数，这样对多核利用率更好)那么并发的效率也就更高，提升是按几何倍数进行的，大家想想nginx，它就采用此模式，所以它刚推出来的时候其并发处理能力是apache服务器的数倍，现在nginx已经和apache一样普及了，事件驱动的异步机制功不可没。
来源：oschina
链接：https://my.oschina.net/u/2318885/blog/602120