LiteFlow v2.15.0 发布：拥抱虚拟线程，告别JVM参数！

概述

各位 LiteFlow 的使用者，大家好！

历经四个月的持续迭代，LiteFlow v2.15.0 正式发布！这是一个里程碑式的版本，共包含了 4 个新特性、7 项重要增强以及 7 个问题修复，累计解决了 18 个 issue。

至于为何版本号从 2.13.2 直接跳到了 2.15.0。其实也没啥特别的原因，可能是因为风水问题吧。

言归正传，对于正在使用 2.13.X 版本的用户，新版本在绝大多数场景下都能做到无缝兼容。我们对从 JDK 8 到 JDK 25 的所有主流版本进行了严苛测试，超过 2000 个测试用例确保了 LiteFlow 框架在各种 JDK 环境下的稳定运行。

平滑支持JDK8~JDK25的所有版本

在旧版本中，LiteFlow 虽然支持 JDK 8 至 17，但在 JDK 9 以上环境中运行时，需要用户额外添加 JVM 参数。其根本原因在于 LiteFlow 底层对 sun.* 包的部分反射调用，而这些内部 API 在高版本 JDK 中受到了严格的封装限制。

在新版本中，我们通过替换底层实现，彻底解决了这一问题。现在，无论您使用哪个 JDK 版本，运行 LiteFlow 都再也无需添加任何额外的 JVM 参数，体验更加平滑顺畅。

全面拥抱 JDK 21 虚拟线程

作为 JDK 21 中最核心的特性之一，虚拟线程能以极低的调度开销，显著提升高 I/O 密集型应用的性能。针对社区中大家高度关注的 JDK 21 及虚拟线程支持问题，我们在此版本中给出了完整的回应。

当您的应用运行在 JDK 21 及以上环境时，LiteFlow 内部的所有异步线程都将自动切换为虚拟线程，充分释放新版 JDK 的性能红利。而在 JDK 21 以下版本，框架则会平稳地回退至使用传统的平台线程。

更棒的是，无论您使用哪个 JDK 版本，都只需引入同一套依赖，无需任何版本区分。

支持 EL 表达式的即时执行

我们收到了许多社区反馈：对于一些简单的动态规则，通过 XML 定义 chain 显得过于繁琐，而每次都用代码动态构建又存在性能开销和手动清理的麻烦。

为此，2.15.0 版本引入了直接执行 EL 规则的新能力。

LiteflowResponse response = flowExecutor.execute2RespWithEL("THEN(a, b, c)", requestData, CustomContext.class);

现在，您可以直接执行一个 EL 表达式来完成流程编排，无需预先创建 chain。并且您完全不必担心性能问题——对于相同的 EL 表达式，框架只会在首次执行时编译一次，后续调用将直接复用缓存，高效可靠。

引入活跃规则的缓存策略

对于拥有海量规则（例如上万条）的复杂系统，此特性将带来显著的内存优化。

我们引入了一套全新的缓存策略。当系统中的规则过多时，该策略会自动维持 N 条最活跃规则的缓存，并将不活跃的规则从内存中卸载，从而有效避免堆内存的持续增长。当被卸载的规则再次被调用时，框架会自动重新编译并将其纳入活跃队列。

整个过程对用户完全透明。该策略默认关闭，您可以通过以下配置开启并调整：

# 是否开启保活策略
liteflow.chain-cache.enabled=true
# 保持活跃chain的数目，默认为10000
liteflow.chain-cache.capacity=10000
# 模式一定得为PARSE_ONE_ON_FIRST_EXEC
liteflow.parse-mode=PARSE_ONE_ON_FIRST_EXEC

隐式子流程的改版

我们必须承认，旧版的隐式子流程在设计上存在诸多局限。为了兼容该特性，框架的许多核心功能不得不做出妥协，导致部分实现变得复杂且不够优雅，这一直是我们维护者心中的一个痛点。

因此，我们曾考虑彻底移除该功能。但考虑到这会给现有用户带来较大的迁移成本，我们最终选择了一条更优的路径：在保留原有调用方式的基础上，对其底层实现进行了彻底重构。

这次重构不仅理顺了内部逻辑，也为未来的功能扩展扫清了障碍。对于正在使用隐式子流程的用户，迁移过程非常简单，仅需将获取子流程请求数据的方法名从 getSubRequestData 统一更改为 getDataRequest 即可。

关于社区答疑

我们始终珍视社区的力量，并长期致力于为开发者提供免费的技术支持。随着 LiteFlow 社区的不断壮大（目前已拥有16个微信交流群），我们发现难以确保每一位开发者的问题都能得到及时和深入的解答。

为了提供更高效、更专注的答疑服务， 您可以选择加入LF CLUB知识星球。在星球里：

• 每一个问题都会得到详尽的解答。

• 沉淀了大量高质量的知识库文章、案例实践和深度解析。

具体加入方式请查看 LiteFlow 官方网站。

完整更新列表

特性 #ICUMKV 全面支持jdk21，以及支持jdk21中的虚拟线程

https://gitee.com/dromara/liteFlow/issues/ICUMKV

特性 #IBQCWB Liteflow的执行器FlowExecutor支持执行EL表达式，而不需要传入chainId

https://gitee.com/dromara/liteFlow/issues/IBQCWB

特性 #IAY66T 建立一种机制保证在过多的规则下只维持前N条最活跃的规则缓存

https://gitee.com/dromara/liteFlow/issues/IAY66T

特性 #ICM6TX WHEN 并行编排增加关键字实现完成任务达到百分比阈值时方可放行

https://gitee.com/dromara/liteFlow/issues/ICM6TX

增强 #ICO3IK 在switch节点中，希望能拿到target的列表信息

https://gitee.com/dromara/liteFlow/issues/ICO3IK

增强 #ICUEG9 JDK支持度更加平滑

https://gitee.com/dromara/liteFlow/issues/ICUEG9

增强 #ICANTH 隐式子流程改版

https://gitee.com/dromara/liteFlow/issues/ICANTH

增强 #IC9GTV 脚本ScriptValidator新增返回ValidationResp的API

https://gitee.com/dromara/liteFlow/issues/IC9GTV

增强 #ICGGAW redis数据源支持集群模式

https://gitee.com/dromara/liteFlow/issues/ICGGAW

增强 #ICR1PL AND关键字的逻辑和语意明确点

https://gitee.com/dromara/liteFlow/issues/ICR1PL

增强 #ICU7Z4 升级liteflow的一些依赖

https://gitee.com/dromara/liteFlow/issues/ICU7Z4

修复 #ICPDU7 Slot的conditionStack在多线程并发时无法保证Condition的弹栈压栈顺序

https://gitee.com/dromara/liteFlow/issues/ICPDU7

修复 #ICO23A Spring设置BeanFactory的cacheBeanMetadata属性为false时，Liteflow项目无法注册声明式组件，后续解析EL失败，项目无法启动

https://gitee.com/dromara/liteFlow/issues/ICO23A

修复 #ICJGIK PARSE_ONE_ON_FIRST_EXEC 模式下 Node 对象执行 Java 脚本 最终 instance.isEnd() 判断空指针问题

https://gitee.com/dromara/liteFlow/issues/ICJGIK

修复 #IC9ZZ8 reids poll模式代码问题

https://gitee.com/dromara/liteFlow/issues/IC9ZZ8

修复 #IC8UPJ 规则EL校验在liteflow.parse-mode=PARSE_ONE_ON_FIRST_EXEC时失效

https://gitee.com/dromara/liteFlow/issues/IC8UPJ

修复 #IC71HA 在线程1的执行过程中线程2去remove chain导致的线程1无法平滑继续执行的bug

https://gitee.com/dromara/liteFlow/issues/IC71HA

修复 #IC2F4F 模糊文件路径的监听，添加新的规则文件没有自动加载

https://gitee.com/dromara/liteFlow/issues/IC2F4F