dead lock when using braft together

**Describe the bug (描述bug)**
用braft的example atomic做测试，将atomic的 Atomic类单独实现，编译成一个.so,再讲so链接到server上，启动server会发生死锁，一直cpu 100%将分开的类Atomic的cpp文件与server文件一起编译，可以正常启动，gdb查看了一下调用栈，在bthread中死锁了，使用的版本brpc1.5，brpc1.0左右，用brpc + braft做过一些应用，无论一起编译还是分开编译，都可以正常运行，记忆里1.0之后对协程锁有过升级，是否是升级引入的新问题？
#0 0x000055e84718fc20 in pthread_once@plt ()
#1 0x000055e8472c158f in bthread::first_sys_pthread_mutex_lock (mutex=0x55e8497432c8) at /src/bthread/mutex.cpp:431
#2 0x00007f9d4c2ea999 in google::protobuf::internal::OnShutdownRun(void (*)(void const*), void const*) () from /home/ubuntu/miniconda3/envs/ea-dev/lib/libprotobuf.so.31
#3 0x00007f9d4c2e2eef in google::protobuf::internal::InitProtobufDefaultsSlow() () from /lib/libprotobuf.so.31
#4 0x00007f9d4c382de6 in google::protobuf::(anonymous namespace)::AddDescriptorsImpl(google::protobuf::internal::DescriptorTable const*) [clone .constprop.0] () from /home/ubuntu/miniconda3/envs/ea-dev/lib/libprotobuf.so.31
#5 0x00007f9d4c91447e in call_init (l=, argc=argc@entry=7, argv=argv@entry=0x7ffca51ad418, env=env@entry=0x7ffca51ad458) at ./elf/dl-init.c:70
#6 0x00007f9d4c914568 in call_init (env=0x7ffca51ad458, argv=0x7ffca51ad418, argc=7, l=) at ./elf/dl-init.c:33
#7 _dl_init (main_map=0x7f9d4c9492e0, argc=7, argv=0x7ffca51ad418, env=0x7ffca51ad458) at ./elf/dl-init.c:117
#8 0x00007f9d4c92e2ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9 0x0000000000000007 in ?? ()
#10 0x00007ffca51af018 in ?? ()
#11 0x00007ffca51af021 in ?? ()
#12 0x00007ffca51af039 in ?? ()
#13 0x00007ffca51af052 in ?? ()
#14 0x00007ffca51af071 in ?? ()
#15 0x00007ffca51af081 in ?? ()

**To Reproduce (复现方法)**
必现

**Expected behavior (期望行为)**
正常运行

**Versions (各种版本)**
OS: ubuntu
Compiler: gcc
brpc:1.5
protobuf:master

**Additional context/screenshots (更多上下文/截图)**

Reproduce the braft example atomic setup by compiling its Atomic class into a shared library and linking it to the server, then compare it with compiling the Atomic and server C++ files together. Start at bthread/mutex.cpp:431 and inspect the shown protobuf initialization stack in gdb. Done means the shared-library setup starts normally without a deadlock or sustained 100% CPU.

Written by the indexing model from the issue text.