Regal

It's fixed by me. Glad to make a pr.

BTW I am glad to fix this issue if necessary.

在builtin service（包括/brpc_metrics和/vars）中访问metric时，不论访问一维（对应VarMapWithLock）还是多维（对应MVarMapWithLock），这里都使用的是pthread mutex。在bthread（builtin service是在bthread中执行的）中使用pthread同步原语是不正确的，可能造成死锁的用法。 作者描述的这种情况造成死锁的原因可能是：处理brpc_metrics服务的bthread所在的pthread worker先占用了MVarMapWithLock 中的pthread mutex，随后在对mvar get_value时通过PassiveStatus自定义的计算函数访问了某个bthread锁并产生了yield。问题的关键在于该bthread唤醒后可能不在原先的pthread worker上，此时再去对MVarMapWithLock的pthread mutex进行解锁是undefined behavior。下一次再访问到该pthread mutex加锁时，由于锁仍被占用而导致死锁。 由于业务代码可能在PassiveStatus自定义的计算函数中确实有加锁保护的需求，通过在文档中强调避免这种写法，不是最优做法，或者很难避免这种死锁问题出现。 正确做法是VarMapWithLock以及MVarMapWithLock应该使用bthread锁来保护，原先的写法属于是bug。将锁改用bthread锁后问题应该能解决。但在bazel编译的情况下，bthread模块由于使用了bvar，编译会依赖bvar模块，而bvar模块要想使用bthread锁又需依赖bthread模块，造成循环依赖，要解决循环依赖得对相关模块结构进行重构，改动不小 😞

> 百度内部好像是用的 service_latency{valid="false",quantile="avg"} 这种方式，也是仓库现有的实现，是个bug，不符合Prometheus规范，接入Prometheus会报错，可以用promtool检查brpc_metrics输出的格式。 原因是quantile=后面接的只能是数字，不能是"avg"诸如此类。

curl ip:port/memory to see memory usage?

> 我看test下面那个BUILD.bazel里面的测试不全，有很多ut文件都没覆盖到，可以更新的全面一些吗？ > [@oathdruid](https://github.com/oathdruid) @yanglimingcn see https://github.com/apache/brpc/issues/2904