理解Drools工作内存与事实对象状态
drools规则引擎的核心是其工作内存（working memory），它存储着所有参与规则评估的事实对象。当一个对象被插入到工作内存中时，drools会根据该对象的当前状态来评估所有适用的规则。然而，drools并不会实时监控外部对这些事实对象的修改。这意味着，如果一个事实对象（例如，java bean）的某个属性在drools工作内存之外被修改了，或者即使在规则的then部分中对一个不直接是规则左侧条件的对象进行了修改，drools的工作内存并不会自动感知到这些变化，从而导致依赖这些属性的when条件无法正确重新评估。
考虑以下场景：一个规则旨在根据TradeEvent的特定属性以及PanicButtonManager的panicModeEnabled状态来激活。
rule "Restrict Trade on Panic Mode" when $tradeEvent : TradeEvent(bookShortName == "FMBTHQLA") $panicManager : PanicButtonManager(panicModeEnabled) // 期望当panicModeEnabled为true时匹配 then // ... 规则动作 ... end
如果PanicButtonManager的panicModeEnabled字段在Drools会话外部被设置为true，或者在某个规则的then部分中被修改，但Drools工作内存未被显式通知，那么上述规则的when部分可能仍然使用panicModeEnabled的旧值进行评估。
问题现象：when条件不更新，但then中值正确
一个常见的困惑是，开发者可能会发现，在规则的then部分中访问PanicButtonManager对象的panicModeEnabled字段时，它显示的是最新的、正确的值。然而，规则的when部分却似乎仍在使用旧值进行匹配。
rule "Restrict Trade on Panic Mode and Log Status"
when
$tradeEvent : TradeEvent(bookShortName == "FMBTHQLA")
$panicManager : PanicButtonManager(panicModeEnabled) // 此处条件可能未更新
then
modify ($tradeEvent) {
messageCode = "PM003",
message = "HQLA: FMBTHQLA is restricted to HQLA mode. Panic status: " + $panicManager.isPanicModeEnabled(), // 此处打印的是最新值
tradeValidationStatus = STATUS.ERROR
}
end这种矛盾的产生原因在于：
- when部分的条件评估是基于Drools工作内存中事实对象的“快照”进行的。如果该快照未更新，条件就不会重新评估。
- then部分中的代码直接操作的是Java对象本身。当通过$panicManager.isPanicModeEnabled()访问字段时，它会从实际的Java对象中读取当前值，而不是Drools工作内存中的内部“快照”值。
因此，即使Java对象本身的状态已经改变，如果Drools工作内存没有被告知这个变化，它就不会重新评估依赖于该状态的规则条件。
解决方案：使用update()显式更新事实
为了让Drools工作内存感知到事实对象状态的变化，并触发规则的重新评估，我们需要显式地调用update()方法。update()方法通知Drools，工作内存中某个事实对象的状态已经改变，因此所有依赖于该事实的规则都需要重新匹配。
update()方法的使用
当PanicButtonManager对象的panicModeEnabled字段在Drools会话外部被修改后，或者在某个规则的then部分中被修改后，为了让其他规则能够感知到这个变化，我们需要在修改发生后调用update()。
例如，如果在一个规则中修改了PanicButtonManager的状态，并希望这个修改能立即影响到其他规则的匹配：
rule "Toggle Panic Mode" when // ... 某些条件触发恐慌模式切换 ... $panicManager : PanicButtonManager() then // 假设这里根据某些逻辑改变了panicModeEnabled $panicManager.setPanicModeEnabled(true); // 关键步骤：通知Drools该事实已更新 update($panicManager); end
在上述示例中，update($panicManager)是至关重要的一步。它告诉Drools：$panicManager这个事实对象的状态已经改变了，请重新评估所有可能受其影响的规则。
update()与modify()的区别
值得注意的是，Drools还提供了modify语句。modify语句通常用于在规则的then部分中，对规则左侧（LHS）匹配到的事实对象进行修改。modify语句实际上是update的一种语法糖，它会自动处理对指定事实的更新。
rule "Modify Trade Event Status"
when
$tradeEvent : TradeEvent(status == STATUS.NEW)
then
modify ($tradeEvent) { // modify 语句会自动调用 update($tradeEvent)
status = STATUS.PROCESSING,
message = "Processing trade event"
}
end然而，modify语句通常只用于直接在规则的then部分中修改那些在when部分被匹配到的事实。如果一个事实对象是在规则的then部分中被间接修改（例如，通过调用其方法修改其内部状态，而不是直接赋值），或者在Drools会话外部被修改，那么就需要显式地调用update()方法。
在原始问题中，modify ($tradeEvent)是正确的，因为它更新了TradeEvent这个事实。但PanicButtonManager的状态改变并未通过update($panicManager)通知Drools，这导致了when条件不更新的问题。
注意事项与最佳实践
-
何时使用update()： 只要工作内存中的事实对象状态发生改变，并且你希望这些改变能触发规则的重新评估时，就应该调用update()。这包括：
- 在Drools会话外部修改了已插入的事实对象。
- 在规则的then部分中，通过Java代码（而非modify语句）修改了某个事实对象。
- 在规则的then部分中，修改了未在when部分直接匹配但仍存在于工作内存中的事实对象。
- 性能考量： 频繁地调用update()可能会对性能产生影响，因为它会导致Drools重新评估所有可能受影响的规则。在设计规则时，应尽量减少不必要的update()调用。
- 精确性： 仅对实际发生变化的事实对象调用update()。
- retract()与insert()： 如果一个事实对象的变化非常大，以至于其身份或主要特征发生了根本性改变，或者你希望将其从工作内存中移除并以新状态重新插入，可以考虑使用retract(fact)和insert(newFact)的组合。但这通常比update()更重，应谨慎使用。
总结
在Drools规则引擎中，确保规则能够对事实对象状态的变化做出正确响应是构建高效规则系统的关键。当外部或间接修改了工作内存中已存在的事实对象时，必须显式调用update()方法来通知Drools工作内存，从而触发规则的重新评估。理解update()机制及其与modify()的区别，是避免Drools规则行为不符合预期，并充分发挥其强大推理能力的重要一步。通过正确使用update()，我们可以确保Drools规则始终基于最新的数据进行决策。
