两种异步模型与深度解析Future接口 高并发 (两种异步模型的优缺点)
本文目录导航：
「高并发」两种异步模型与深度解析Future接口-
大家好，我是冰河~~
本文有点长，但是满满的干货，以实际案例的形式分析了两种异步模型，并从源码角度深度解析Future接口和FutureTask类，希望大家踏下心来，打开你的IDE，跟着文章看源码，相信你一定收获不小！
在Java的并发编程中，大体上会分为两种异步编程模型，一类是直接以异步的形式来并行运行其他的任务，不需要返回任务的结果数据。
一类是以异步的形式运行其他任务，需要返回结果。
1.无返回结果的异步模型
无返回结果的异步任务，可以直接将任务丢进线程或线程池中运行，此时，无法直接获得任务的执行结果数据，一种方式是可以使用回调方法来获取任务的运行结果。
具体的方案是：定义一个回调接口，并在接口中定义接收任务结果数据的方法，具体逻辑在回调接口的实现类中完成。
将回调接口与任务参数一同放进线程或线程池中运行，任务运行后调用接口方法，执行回调接口实现类中的逻辑来处理结果数据。
这里，给出一个简单的示例供参考。
便于接口的通用型，这里为回调接口定义了泛型。
回调接口的实现类主要用来对任务的返回结果进行相应的业务处理，这里，为了方便演示，只是将结果数据返回。
大家需要根据具体的业务场景来做相应的分析和处理。
任务的执行类是具体执行任务的类，实现Runnable接口，在此类中定义一个回调接口类型的成员变量和一个String类型的任务参数（模拟任务的参数），并在构造方法中注入回调接口和任务参数。
在run方法中执行任务，任务完成后将任务的结果数据封装成TaskResult对象，调用回调接口的方法将TaskResult对象传递到回调方法中。
到这里，整个大的框架算是完成了，接下来，就是测试看能否获取到异步任务的结果了。
在测试类中，使用Thread类创建一个新的线程，并启动线程运行任务。
运行程序最终的接口数据如下所示。
大家可以细细品味下这种获取异步结果的方式。
这里，只是简单的使用了Thread类来创建并启动线程，也可以使用线程池的方式实现。
大家可自行实现以线程池的方式通过回调接口获取异步结果。
2.有返回结果的异步模型
尽管使用回调接口能够获取异步任务的结果，但是这种方式使用起来略显复杂。
在JDK中提供了可以直接返回异步结果的处理方案。
最常用的就是使用Future接口或者其实现类FutureTask来接收任务的返回结果。
使用Future接口往往配合线程池来获取异步执行结果，如下所示。
运行结果如下所示。
FutureTask类既可以结合Thread类使用也可以结合线程池使用，接下来，就看下这两种使用方式。
结合Thread类的使用示例如下所示。
运行结果如下所示。
结合线程池的使用示例如下。
运行结果如下所示。
可以看到使用Future接口或者FutureTask类来获取异步结果比使用回调接口获取异步结果简单多了。
注意：实现异步的方式很多，这里只是用多线程举例。
接下来，就深入分析下Future接口。
接口
Future是JDK1.5新增的异步编程接口，其源代码如下所示。
可以看到，在Future接口中，总共定义了5个抽象方法。
接下来，就分别介绍下这5个方法的含义。
取消任务的执行，接收一个boolean类型的参数，成功取消任务，则返回true，否则返回false。
当任务已经完成，已经结束或者因其他原因不能取消时，方法会返回false，表示任务取消失败。
当任务未启动调用了此方法，并且结果返回true（取消成功），则当前任务不再运行。
如果任务已经启动，会根据当前传递的boolean类型的参数来决定是否中断当前运行的线程来取消当前运行的任务。
判断任务在完成之前是否被取消，如果在任务完成之前被取消，则返回true；否则，返回false。
这里需要注意一个细节：只有任务未启动，或者在完成之前被取消，才会返回true，表示任务已经被成功取消。
其他情况都会返回false。
判断任务是否已经完成，如果任务正常结束、抛出异常退出、被取消，都会返回true，表示任务已经完成。
当任务完成时，直接返回任务的结果数据；当任务未完成时，等待任务完成并返回任务的结果数据。
当任务完成时，直接返回任务的结果数据；当任务未完成时，等待任务完成，并设置了超时等待时间。
在超时时间内任务完成，则返回结果；否则，抛出TimeoutException异常。
接口
Future接口有一个重要的子接口，那就是RunnableFuture接口，RunnableFuture接口不但继承了Future接口，而且继承了接口，其源代码如下所示。
这里，问一下，RunnableFuture接口中有几个抽象方法？想好了再说！哈哈哈。
。
。
这个接口比较简单run()方法就是运行任务时调用的方法。
类
FutureTask类是RunnableFuture接口的一个非常重要的实现类，它实现了RunnableFuture接口、Future接口和Runnable接口的所有方法。
FutureTask类的源代码比较多，这个就不粘贴了，大家自行到下查看。
（1）FutureTask类中的变量与常量
在FutureTask类中首先定义了一个状态变量state，这个变量使用了volatile关键字修饰，这里，大家只需要知道volatile关键字通过内存屏障和禁止重排序优化来实现线程安全，后续会单独深度分析volatile关键字是如何保证线程安全的。
紧接着，定义了几个任务运行时的状态常量，如下所示。
其中，代码注释中给出了几个可能的状态变更流程，如下所示。
接下来，定义了其他几个成员变量，如下所示。
又看到我们所熟悉的Callable接口了，Callable接口那肯定就是用来调用call()方法执行具体任务了。
看一下WaitNode类的定义，如下所示。
可以看到，WaitNode类是FutureTask类的静态内部类，类中定义了一个Thread成员变量和指向下一个WaitNode节点的引用。
其中通过构造方法将thread变量设置为当前线程。
（2）构造方法
接下来，是FutureTask的两个构造方法，比较简单，如下所示。
（3）是否取消与完成方法
继续向下看源码，看到一个任务是否取消的方法，和一个任务是否完成的方法，如下所示。
这两方法中，都是通过判断任务的状态来判定任务是否已取消和已完成的。
为啥会这样判断呢？再次查看FutureTask类中定义的状态常量发现，其常量的定义是有规律的，并不是随意定义的。
其中，大于或者等于CANCELLED的常量为CANCELLED、INTERRUPTING和INTERRUPTED，这三个状态均可以表示线程已经被取消。
当状态不等于NEW时，可以表示任务已经完成。
通过这里，大家可以学到一点：以后在编码过程中，要按照规律来定义自己使用的状态，尤其是涉及到业务中有频繁的状态变更的操作，有规律的状态可使业务处理变得事半功倍，这也是通过看别人的源码设计能够学到的，这里，建议大家还是多看别人写的优秀的开源框架的源码。
（4）取消方法
我们继续向下看源码，接下来，看到的是cancel(boolean)方法，如下所示。
接下来，拆解cancel(boolean)方法。
在cancel(boolean)方法中，首先判断任务的状态和CAS的操作结果，如果任务的状态不等于NEW或者CAS的操作返回false，则直接返回false，表示任务取消失败。
如下所示。
接下来，在try代码块中，首先判断是否可以中断当前任务所在的线程来取消任务的运行。
如果可以中断当前任务所在的线程，则以一个Thread临时变量来指向运行任务的线程，当指向的变量不为空时，调用线程对象的interrupt()方法来中断线程的运行，最后将线程标记为被中断的状态。
如下所示。
这里，发现变更任务状态使用的是()方法，这个方法是个什么鬼呢？点进去看一下，如下所示。
可以看到，又是一个本地方法，嘿嘿，这里先不管它，后续文章会详解这些方法的作用。
接下来，cancel(boolean)方法会进入finally代码块，如下所示。
可以看到在finallly代码块中调用了finishCompletion()方法，顾名思义，finishCompletion()方法表示结束任务的运行，接下来看看它是如何实现的。
点到finishCompletion()方法中看一下，如下所示。
在finishCompletion()方法中，首先定义一个for循环，循环终止因子为waiters为null，在循环中，判断CAS操作是否成功，如果成功进行if条件中的逻辑。
首先，定义一个for自旋循环，在自旋循环体中，唤醒WaitNode堆栈中的线程，使其运行完成。
当WaitNode堆栈中的线程运行完成后，通过break退出外层for循环。
接下来调用done()方法。
done()方法又是个什么鬼呢？点进去看一下，如下所示。
可以看到，done()方法是一个空的方法体，交由子类来实现具体的业务逻辑。
当我们的具体业务中，需要在取消任务时，执行一些额外的业务逻辑，可以在子类中覆写done()方法的实现。
（5）get()方法
继续向下看FutureTask类的代码，FutureTask类中实现了两个get()方法，如下所示。
没参数的get()方法为当任务未运行完成时，会阻塞，直到返回任务结果。
有参数的get()方法为当任务未运行完成，并且等待时间超出了超时时间，会TimeoutException异常。
两个get()方法的主要逻辑差不多，一个没有超时设置，一个有超时设置，这里说一下主要逻辑。
判断任务的当前状态是否小于或者等于COMPLETING，也就是说，任务是NEW状态或者COMPLETING，调用awaitDone()方法，看下awaitDone()方法的实现，如下所示。
接下来，拆解awaitDone()方法。
在awaitDone()方法中，最重要的就是for自旋循环，在循环中首先判断当前线程是否被中断，如果已经被中断，则调用removeWaiter()将当前线程从堆栈中移除，并且抛出InterruptedException异常，如下所示。
接下来，判断任务的当前状态是否完成，如果完成，并且堆栈句柄不为空，则将堆栈中的当前线程设置为空，返回当前任务的状态，如下所示。
当任务的状态为COMPLETING时，使当前线程让出CPU资源，如下所示。
如果堆栈为空，则创建堆栈对象，如下所示。
如果queued变量为false，通过CAS操作为queued赋值，如果awaitDone()方法传递的timed参数为true，则计算超时时间，当时间已超时，则在堆栈中移除当前线程并返回任务状态，如下所示。
如果未超时，则重置超时时间，如下所示。
如果不满足上述的所有条件，则将当前线程设置为等待状态，如下所示。
接下来，回到get()方法中，当awaitDone()方法返回结果，或者任务的状态不满足条件时，都会调用report()方法，并将当前任务的状态传递到report()方法中，并返回结果，如下所示。
看来，这里还要看下report()方法啊，点进去看下report()方法的实现，如下所示。
可以看到，report()方法的实现比较简单，首先，将outcome数据赋值给x变量，接下来，主要是判断接收到的任务状态，如果状态为NORMAL，则将x强转为泛型类型返回；当任务的状态大于或者等于CANCELLED，也就是任务已经取消，则抛出CancellationException异常，其他情况则抛出ExecutionException异常。
至此，get()方法分析完成。
注意：一定要理解get()方法的实现，因为get()方法是我们使用Future接口和FutureTask类时，使用的比较频繁的一个方法。
（6）set()方法与setException()方法
继续看FutureTask类的代码，接下来看到的是set()方法与setException()方法，如下所示。
通过源码可以看出，set()方法与setException()方法整体逻辑几乎一样，只是在设置任务状态时一个将状态设置为NORMAL，一个将状态设置为EXCEPTIONAL。
至于finishCompletion()方法，前面已经分析过。
（7）run()方法与runAndReset()方法
接下来，就是run()方法了，run()方法的源代码如下所示。
可以这么说，只要使用了Future和FutureTask，就必然会调用run()方法来运行任务，掌握run()方法的流程是非常有必要的。
在run()方法中，如果当前状态不是NEW，或者CAS操作返回的结果为false，则直接返回，不再执行后续逻辑，如下所示。
接下来，在try代码块中，将成员变量callable赋值给一个临时变量c，判断临时变量不等于null，并且任务状态为NEW，则调用Callable接口的call()方法，并接收结果数据。
并将ran变量设置为true。
当程序抛出异常时，将接收结果的变量设置为null，ran变量设置为false，并且调用setException()方法将任务的状态设置为EXCEPTIONA。
接下来，如果ran变量为true，则调用set()方法，如下所示。
接下来，程序会进入finally代码块中，如下所示。
这里，将runner设置为null，如果任务的当前状态大于或者等于INTERRUPTING，也就是线程被中断了。
则调用handlePossibleCancellationInterrupt()方法，接下来，看下handlePossibleCancellationInterrupt()方法的实现。
可以看到，handlePossibleCancellationInterrupt()方法的实现比较简单，当任务的状态为INTERRUPTING时，使用while()循环，条件为当前任务状态为INTERRUPTING，将当前线程占用的CPU资源释放，也就是说，当任务运行完成后，释放线程所占用的资源。
runAndReset()方法的逻辑与run()差不多，只是runAndReset()方法会在finally代码块中将任务状态重置为NEW。
runAndReset()方法的源代码如下所示，就不重复说明了。
（8）removeWaiter()方法
removeWaiter()方法中主要是使用自旋循环的方式来移除WaitNode中的线程，比较简单，如下所示。
最后，在FutureTask类的最后，有如下代码。
关于这些代码的作用，会在后续深度解析CAS文章中详细说明，这里就不再探讨。
至此，关于Future接口和FutureTask类的源码就分析完了。
好了，今天就到这儿吧，我是冰河，我们下期见~~
为什么高并发普遍用java不用c++,c#,rust或go?
为何高并发开发中普遍选择Java而不选用C++, C#, Rust 或 Go？这主要因为C/C++的性能优势相较于十年前已不如往日。
在二十年前，计算机内存一般在几十兆到几百兆之间，CPU单核运行，而同期的Java程序运行速度相对较慢。
到了十年前，计算机内存以G为单位，CPU多核心化，Java开始进入中心舞台，取代了C/C++在高性能和高并发领域的地位。
现在，硬件性能至少提升了一百倍，高并发开发中已不再提及C/C++。
硬件性能决定了上层软件的格局。
硬件性能的提升，使得使用更高效、更易于维护的上层软件成为可能。
招聘一个C/C++开发团队，成本高昂，可能每年上百万。
相比之下，仅仅通过硬件性能的提升就能节省这高昂的开销。
举例来说，关于边缘计算平台Fox-Edge是否支持SQLite的问题。
在Fox-Edge中，MySQL是消耗内存最大的组件，有用户提出是否可以支持SQLite以节省内存开销。
考虑到去年主流的高端ARM嵌入式设备规格为4核CPU/4G内存，而今年4核CPU/8G内存规格开始普及，硬件性能的提升使得使用更优化的数据库解决方案成为可能。
一般互联网公司 如何进行高并发的架构
一、什么是高并发高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。
响应时间：系统对请求做出响应的时间。
例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。
吞吐量：单位时间内处理的请求数量。
QPS：每秒响应请求数。
在互联网领域，这个指标和吞吐量区分的没有这么明显。
并发用户数：同时承载正常使用系统功能的用户数量。
例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
二、如何提升系统的并发能力互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
垂直扩展：提升单机处理能力。
垂直扩展的方式又有两种：（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。
不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。
所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
水平扩展：只要增加服务器数量，就能线性扩充系统性能。
水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。
三、常见的互联网分层架构常见互联网分布式架构如上，分为：（1）客户端层：典型调用方是浏览器browser或者手机应用APP（2）反向代理层：系统入口，反向代理（3）站点应用层：实现核心应用逻辑，返回html或者json（4）服务层：如果实现了服务化，就有这一层（5）数据-缓存层：缓存加速访问存储（6）数据-数据库层：数据库固化数据存储整个系统各层次的水平扩展，又分别是如何实施的呢？四、分层水平扩展架构实践反向代理层的水平扩展反向代理层的水平扩展，是通过“DNS轮询”实现的：dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。
当nginx成为瓶颈的时候，只要增加服务器数量，新增nginx服务的部署，增加一个外网ip，就能扩展反向代理层的性能，做到理论上的无限高并发。
站点层的水平扩展站点层的水平扩展，是通过“nginx”实现的。
通过修改，可以设置多个web后端。
当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。
服务层的水平扩展服务层的水平扩展，是通过“服务连接池”实现的。
站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。
如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。
数据层的水平扩展在数据量很大的情况下，数据层（缓存，数据库）涉及数据的水平扩展，将原本存储在一台服务器上的数据（缓存，数据库）水平拆分到不同服务器上去，以达到扩充系统性能的目的。
互联网数据层常见的水平拆分方式有这么几种，以数据库为例：按照范围水平拆分每一个数据服务，存储一定范围的数据，上图为例：这个方案的好处是：（1）规则简单，service只需判断一下uid范围就能路由到对应的存储服务；（2）数据均衡性较好；（3）比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务；不足是：（1）请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大；按照哈希水平拆分每一个数据库，存储某个key值hash后的部分数据，上图为例：这个方案的好处是：（1）规则简单，service只需对uid进行hash能路由到对应的存储服务；（2）数据均衡性较好；（3）请求均匀性较好；不足是：（1）不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移；这里需要注意的是，通过水平拆分来扩充系统性能，与主从同步读写分离来扩充数据库性能的方式有本质的不同。
通过水平拆分扩展数据库性能：（1）每个服务器上存储的数据量是总量的1/n，所以单机的性能也会有提升；（2）n个服务器上的数据没有交集，那个服务器上数据的并集是数据的全集；（3）数据水平拆分到了n个服务器上，理论上读性能扩充了n倍，写性能也扩充了n倍（其实远不止n倍，因为单机的数据量变为了原来的1/n）；通过主从同步读写分离扩展数据库性能：（1）每个服务器上存储的数据量是和总量相同；（2）n个服务器上的数据都一样，都是全集；（3）理论上读性能扩充了n倍，写仍然是单点，写性能不变；缓存层的水平拆分和数据库层的水平拆分类似，也是以范围拆分和哈希拆分的方式居多，就不再展开。
五、总结高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。
互联网分层架构中，各层次水平扩展的实践又有所不同：（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；（2）站点层可以通过nginx来进行水平扩展；（3）服务层可以通过服务连接池来进行水平扩展；（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。
phper