Data race is found around PikaServer::statistic_::server_stat::exec_count_db

[cheniujh]

Is this a regression?

No

Description

1 从代码逻辑来看
g_pika_server->statistic_.server_stat.exec_count_db 的类型是：std::unordered_map<std::string, std::atomic<uint64_t>> exec_count_db， value是atomic，用于累加命令执行次数。
这个map主要被使用到的地方是：PikaServer::UpdateQueryNumAndExecCountDB，而这个函数高度并发，大致逻辑如下：

问题其实比较明显：exec_count_db这个map本身无锁，在pika启动以后，最开始的那批负载打进来(此时map为空)，会触发对这个map的并发insert,这无疑是要data race的

2 打开thread sanitizer再跑，验证了1中的逻辑推断，这个map有datarace，而且用address sanitizer再跑的话，报的问题是heap use the after free, 典型的并发保护没做好：

1. From the code logic perspective, the type of g_pika_server->statistic_.server_stat.exec_count_db is: std::unordered_map<std::string, std::atomic<uint64_t>> exec_count_db. The value is atomic, used to accumulate the number of command executions. This map is mainly used in the function PikaServer::UpdateQueryNumAndExecCountDB, which is highly concurrent. The general logic is as follows:
   
   The issue is quite obvious: the exec_count_db map itself is lock-free. After Pika starts, the initial batch of loads will trigger concurrent inserts into this map, which undoubtedly causes a data race.

2. Running with Thread Sanitizer confirms the logic inference in point 1, showing that this map has a data race. Additionally, running with Address Sanitizer reports an issue of heap use after free, which is typical of improper concurrent protection:
   

Please provide a link to a minimal reproduction of the bug

No response

Screenshots or videos

No response

Please provide the version you discovered this bug in (check about page for version information)

No response

Anything else?

No response