Spring WebFlux 要革了谁的命？

Java国王昨晚做了一个梦。

梦中有个白胡子老头儿，颇有仙风道骨， 告诉他说：“你们Java啊，实在是太弱了，连一个基本的功能都实现不了!”

国王大为惊奇：“什么功能是我堂堂大Java搞不定的?”

老头儿展示了两行代码：

float salary = 1000; 

float tax =  salary * 0.1; 

国王说：“这不很正常吗，薪水(salary)是1000， 税(tax)等于100，我国小学生都能算出来。”

老头儿说：“我要是现在让salary=2000，那tax等于多少啊?”

“还是100! 因为tax没有被重新计算!”

“薪水变了，为什么税不变呢? ”

“这个......”

看到国王不说话了，老头儿继续说：“你们得建立变量tax和变量salary之间的关联，让他们像Excel一样，一个单元格的值变了，Excel的公式自然会更新另外一个单元格，让它随之变化。”

float salary = 1000; 

//假设这个命令建立了tax和salary之间的关联 

float tax <=  salary *0.1 

salary = 2000 ; 

assertEquals(200,tax);  //现在tax自动变成了200 

国王说道：“你这么做有什么用啊，再说这也不是Java的问题，所有的语言都有这个问题啊......”

仙风道骨的老头儿没有回答， 慢慢消失了。

发布-订阅模式

第二天早朝，国王给大臣们讲了自己这个奇怪的梦，看看谁能帮自己解一解， 没想到大臣们七嘴八舌，说自己也做了同样的梦。

这就奇怪了，难道有神灵故意给大家托梦吗? 在梦中，仙人老头儿给大家举的例子都是一模一样的。

集合大臣小心翼翼地说道：“难道他是在暗示我国的税收太高了吗， 有10%，要降低一点?”

国王瞪了他一眼：“胡说些什么?我们的税一点都不高，起征点提高到了5000，除了五险一金扣除，我们还有房贷减免，租房减免，独生子女减免，赡养老人减免等一系列政策， 怎么能叫高呢?”

集合大臣赶紧噤声。

IO大臣继续说：“陛下不用烦恼，老头儿说的问题，我们Java早已经提供了对应的解决方案，那就是发布者-订阅者模式啊。如果把Salary当成一个数据源的发布者， 把Tax当成一个订阅者，注册到Salary当中， 每当Salary有变化，就发送一个事件给Tax，Tax收到后，做相应的计算就可以了。”

“这不就是一种把数据持续推送给观察者或者订阅者的一种模式嘛，这种小儿科的东西，有什么用?” 老对头线程大臣说道。

“在这个场景下确实没啥用处，但是这种事件流的方式，如果处理好了，也许能解决大问题。” IO大臣虽然不太服气，但是也想不出什么好的应用场景出来。

高并发

国王看到两个老家伙又要干起来，马上转移话题：“听说我们Java在高并发方面遇到了一点儿问题?”

IO大臣立刻兴奋起来，顺杆就爬：“没错，这二十来年，我们Java一直使用Tomcat那种线程池的方式，现在在越来越差劲了，难以应对高并发了。”

这一下子把Tomcat大臣，线程大臣，甚至Servlet大臣都给拉了进来，国王暗自后悔。

IO大臣继续侃侃而谈：“现在的模型每来一个请求都会有一个线程来处理，如果这个请求涉及到IO或者网络操作，这个线程不得不阻塞等待，没法干别的事情。”

“如果用户的请求太多，那线程池中的线程很快就会被用光。这时候就没办法对外提供服务了。”

这确实是实情，基于Servlet的线程模型，就是这么工作的。

国王问道：“那个线程调用RPC服务的时候，为什么要等待呢? 让它去干别的事情，比如处理另外一个请求不就可以了?”