概述

距离上一次发版差不多有快4个月了。这几个月来断断续续的迭代终于带来了全新的2.15.0版本。这个版本一共带来了4个特性，7个增强，7个修复。总共18个issue的更新。

如果要问为什么从2.13.2直接就到2.15.0了。那其实也没啥特别的原因，可能是因为风水问题吧。

言归正传，如果你正在使用2.13.X，应该在99%的场景下是能无缝兼容的。具体那1%是哪个场景，下面会讲。

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

之前LiteFlow支持了JDK8~JDK17，但是在JDK9以上版本中，是需要额外加入jvm参数的。究其原因就是LF的底层用了一些对sun包下的反射调用，而sun包本身却又是强封装类型的。所以必须要参数来解除这一限制。也许有的社区同学没加参数也能运行起来，那是因为没用到相关的特性。

这次我们替换了一些底层方法的调用实现方式，使得现在在任意版本中使用LiteFlow，都无需再加任何jvm参数了

全面支持JDK21以及以上版本的虚拟线程特性

虚拟线程是JDK21中最重要，最大的特性。虚拟线程的调度开销仅仅为平台线程的千分之一，对于高IO的应用来说，虚拟线程可以提升非常多的性能。社区里之前有非常多的小伙伴在询问LF是否支持JDK21，是否支持虚拟线程。现在，全部都已经实现了。

当LF运行在JDK21及以上时，LF中的所有异步线程均会自动的切换到虚拟线程。如果是JDK21以下版本时，那就是普通的平台线程。

并且，不管你是何种版本的JDK，引入的依赖都是同一套，不区分对应的JDK版本。

支持直接执行EL规则

对于执行一些简单的规则，有很多小伙伴反馈去xml里定义一个chain太过于繁琐，而用动态构建，每次都去构建，又太耗性能，而且用完还是自己清理chain。

所以这次，LF推出一个直接执行EL规则的能力。

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

你现在可以直接执行一个规则EL，不用去创建chain了。而且你不用担心每次都去编译构建会耗性能，在新的体系里，如果每个请求都执行相同的EL，只会在第一次时构建1次。

活跃规则保活策略

这个特性对系统中有大量规则的场景非常有用，这里的大量规则是指有上万条规则。能有效避免堆内存的持续扩大。

这个策略会在过多的规则下只维持前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

隐式子流程的改版

隐式子流程这个特性，在LF中是一个非常糟糕的设计。

为了兼容隐式子流程特性，原先的很多特性都在为隐式子流程做妥协。这造就了一些硬代码判断，每次看到这些糟糕的代码时都如鲠在喉。所以我们一度想把这个功能给移除掉，反正作为替代方案，使用者完全可以在组件内另外调起一条流程来实现。

事实上我们也这么做了。但是在移除掉这个特性之后，发现可能使用到隐式子流程的人会非常抓狂，因为毕竟要改一些代码才能用替代方案。所以后面我们专门对隐式子流程做了改版，在保留原先调用方式的基础上，我们更换了底层实现方式。

可能使用到隐式子流程的人，只需要在取请求参数的地方改一下方法名应该就可以了。原先是getSubRequestData，现在统一变成了getDataRequest。

完整更新列表

特性 #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