如何提升Web服务端并发效率的异步编程技术

做为一名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同样普及了，事件驱动的异步机制功不可没。