这里会导致concurrent map writes崩溃 about gengine

[LLLLancelot]

`
*/
func (r *RuleEntity) Execute(dc *context.DataContext) (interface{}, error, bool) {
// r.Vars = make(map[string]reflect.Value)
// defer r.clearMap()
v, e, b := r.RuleContent.Execute(dc, make(map[string]reflect.Value))
if v == reflect.ValueOf(nil) {
return nil, e, b
}
return v.Interface(), e, b
}

func (r *RuleEntity) clearMap() {
// r.Vars = make(map[string]reflect.Value)
}
`
我改成这样的方式，就没有再重现这个问题了，你们可以自己执行一下压测试试。

[rencalo770]

感谢你的测试！
并发读写了同一个map，而不加锁，所以会出现问题。
在“最佳实践文”文档里有多次提到，gengine能保证规则更新等针对引擎自身的操作 线程安全；但对于用户要并发访问非线程安全的数据结构（如普通map），gengine是无法保证其线程安全的。

推荐做法有几种（这其实是所有编程语言的通用做法）：
1.不要共享变量
2.使用并发安全的数据结构
3.使用无状态函数

最佳实践文档：
https://github.com/bilibili/gengine/wiki/%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5

[LLLLancelot]

不是哦，不是用户的并发访问，用的是引擎池的ExecuteSelectedRulesWithControlAndStopTag方法，完全是一个无状态的接口，也不涉及到map的访问。
我压测的时候，是全部执行的同一个规则。

[rencalo770]

非常感谢你的回复！你的说法是对的。
在之前的老版本，因为每个实例独自使用自己的rule_entity, 所以将 r.Vars放在结构体中是不会有并发安全的问题；
后来为了提高规则编译性能，降低内存使用率，所以无状态的rule_entity是pool内多实例共享的，如果这个时候还将Vars放在结构体层次，就会导致并发安全问题。

期待你提个MR：删除RuleEntity中的Vars，然后按照你上面的写法，注释或删除掉你注释的代码行，并删除func (r *RuleEntity) clearMap()函数。

再次感谢你的反馈。

[rencalo770]

两天没等到大佬您，我只好自己提交修复了

[xiaobai5150]

@rencalo770 你好，大佬， 对于规则池的最佳实践，在高并发方面有些疑问，麻烦解答一下；
1： 此框架能否用于高并发的业务场景，我想引入此规则引擎到实时推荐中，QPS在3万左右。
2： 在规则池的最佳实践中，规则池的大小是否需要根据QPS 来设置呢， 如果QPS =3万， 那规则池的大小是否应该设置大于3万。
3： 贵公司是否在 有将此框架用于实时推荐的业务场景，能够共享一下经验，主要还是担心数据并发安全问题。
以上， 期待您的尽快回复， 谢谢！