反应式编程承诺具有较低内存要求的企业Java应用程序的更高性能。通过避免阻塞始终导致操作系统中的进程和上下文切换的调用来实现此承诺。这种上下文切换具有高CPU和存储器开销，当然，这些开关减少了更少。然而，这种反应式编程的性能提升是以软件可维护性较差为代价的。但更高的性能是否物有所值？有哪些替代品？这是本文仔细研究一下。
反应式编程有一些严重的缺点：写入函数和执行代码的分离导致读取和编写代码的难度增加。为这种异步代码编写单元测试也很复杂。调试代码更加困难。
Project Reactor是Spring的Reactive Web Framework的基础，它已经有许多辅助构造，支持测试，调试和上下文传播（请参阅测试，调试和上下文部分）。然而，仅仅需要这种辅助结构这一事实已经揭示了反应式编程的复杂性。因此，问题在于是否存在其他可行的替代方案来解决Java线程的昂贵上下文切换问题。
反应式编程解决了由使用本机线程和“每个请求一个线程”范例引起的性能问题。但是，此解决方案伴随着更高的开发和维护复杂性，因为测试和调试等变得更加复杂。
绿色线程是避免操作系统中的进程交换机造成的性能损失的可能方法。这些在Java 1.1中可用，但已经在Java 1.3中被丢弃，因为它们不允许使用多核或多处理器系统的好处。在JDK中引入另一种Green Threads（所谓的Fibers）的新尝试是Project Loom。这个提议将伴随着对Java作为一种衍生产品的延续的支持。此功能在其他编程语言（如Kotlin和Go，名称为Coroutines）中是已知的。
如果将Project Loom集成到JDK中，以及它对Reactive Programming的分发有何影响，您可能会感到好奇。从性能的角度来看，这可能会使Java世界变得多余：要实现Fibers，Java中线程的执行将分为两部分，即continuation和scheduler。延续表示执行状态，即要执行的代码，包括执行上下文，例如调用参数，堆栈等。然后，调度程序确保所有延续均匀执行。