响应式编程、函数式编程和过程式编程的区别

编程范式这事儿，看似是个基础概念，但真要聊起来，其实挺有意思的。咱们可以先做个简单对比，看看传统的、响应式的、函数式的，还有过程化的，到底各自是怎么玩儿的。

响应式编程

传统的编程方式，说白了就是一步接一步，顺序执行。上一个任务没干完，后面的就得干等着，直到它结束。这种“排队”模式，一旦遇到需要快速响应的场景，就有点捉襟见肘了。所以，一个很自然的思路就是把同步执行换成异步，把“方法执行”变成“消息发送”。这就是异步编程，也是响应式编程的核心特性之一。

那么，响应式编程到底有哪些“杀手锏”呢？

（1）异步编程
它提供了一个相当顺手的异步编程模型，能充分挖掘多核CPU的潜力，提升效率、降低延迟和阻塞。简单说，就是让CPU不闲着，活儿干得更快。

（2）数据流
基于数据流模型，响应式编程给出一套统一的Stream风格的数据处理接口。和Ja va 8中的Stream相比，它不只是支持静态数据流，还能处理动态数据流，并且允许多个订阅者同时接入、复用数据。这就像是从一个只能播放录像带的播放器，升级成了能直播、能点播、还能多人同时看的流媒体平台。

（3）变化传播
这个特性可以理解为：以一个数据流为输入，经过一连串操作，最终转化成另一个数据流，再分发给各个订阅者。这个过程有点像函数式编程里的组合函数——把多个函数串联起来，把一组输入数据加工成格式迥异的输出。关键在于，整个过程是自动传播的，一个环节变了，后续跟着自动调整。

函数式编程

函数式编程是另一种思路，它把电脑运算看作是函数的计算。和过程化编程相比，函数式编程里的函数计算可以随时调用，灵活性更高。

它通过消除全局状态，解决了过程式编程中常见的“牵一发而动全身”的问题。函数式程序员依赖的是那些不修改全局状态的函数，他们唯一使用的状态就是传给函数的参数。一个函数的结果，通常会继续传给下一个函数。换句话说，状态是在函数之间传递的，而不是挂在全局变量上。这样一来，全局状态带来的副作用和其他问题，自然就消除了。

过程化编程

过程式编程就比较传统了，数据存储在全局变量中，通过函数来处理。这种方式在程序规模小的时候还挺好用，但问题出在——程序变大了之后。

因为所有程序状态都堆在全局变量里，一旦程序规模膨胀，就很容易出问题。比如，多个函数都可能读写同一个全局变量，你很难记住到底有哪些地方对它做了修改。很可能一个函数改了某个全局变量的值，后面的另一个函数又改了同样的变量，而写第二个函数的时候，程序员早已忘了第一个函数干过什么。这就会严重破坏数据的准确性。

弊端很明显：功能越多，全局变量越多，修改变量的频率越高，到最后程序根本没法维护。这种编程方式还容易产生副作用，最典型的就是意外改变全局状态。比如，某个看似无关的函数，可能不小心把某个计数器递增了两次。