本周遇到了好几个core都非常有典型性。

在这里和大家分享下。

相信有过Linux编程经验的人，肯定都遇到过。

感觉周围人非常多对core有天然的恐惧感，尤其对刚入行不久的同学来说。当然了。也有工作好几年看到core也束手无策的。今天就分析一下，core，事实上大部分都是非常easy解决的。假设一个core非常难以复现，那么说明还是非常复杂的，算是Corner case。可能须要非常长时间。脑子里要有非常好的执行时状态才干够（阅读源代码，学习的是逻辑。将源代码相应到执行时的状态，分析一些状态机的转换，再去分析可能会发生的情况）。

相信前几篇文章会对这样的Corner case的分析与解决打下比較好的基础。

相反，那种每次必现，或者复现比率非常高的case，是非常easy解决的。

多线程必定出core？

假设是你新增加的代码引入的core，实际上非常easy解决的，简单的对照一下改动的diff。然后看一下是否有比較低级的错误。

假设发现不了，看是否是多线程的问题？单线程假设没有出core，改成多线程就出core。那么就说明多线程竞争某些变量了：同一时候改动某些变量导致出问题。这个时候你可能第一反应会加锁。

我本人非常反感加锁。即使你加锁的粒度非常小，作用域也够小。可是仅仅要是加锁，就代表有堵塞。就代表维护起来会非常麻烦。这些共享变量真的那么值得加锁吗？可否换成局部变量？假设他是一块动态内存。为了调用某个接口时不要频繁申请释放内存（比方这个接口每秒几千次的调用），那么初始化时候申请一块内存是绝对合理的：请把它设置为线程变量吧。

每一个线程初始化时候申请这块内存。

当然了你假设实现的是一个框架或者架构调用的接口，这个接口要做到线程安全的。那么看起来你并不能控制这个线程什么时候启动；线程数目会是多少个，那么就没有办法了吗？

实际上，方法有非常多，比方，你能够在一个map中维护一个“线程”变量的相应关系

__gnu_cxx::hash_map< pid_t, void *> thread_data_map;
void * thread_buffer;
std::map<pid_t, void *>::iterator it;
lock
it = thread_data_map.find(pid);
if (it == thread_data_map.end()) {
    //init "thread data"
    thread_data_map[pid] = create_buffer();
} else {
    thread_buffer = it->second;
}
unlock

这里不得不使用了一个锁。实际上因为线程数是有限的，因此这个效率还好。我本周实现了一个qps能够达到2000+的在线应用，基本上锁的代价在整个的call stack中能够忽略不计。

当然了。比較好的框架可能会提供OnThreadInit这样的接口。那么在这边申请线程变量吧:

int pthread_setspecific (pthread_key_t key, const void *value);

void *pthread_getspecific (pthread_key_t key);

什么时候要使用线程变量？看多线程下是否对该变量有写操作，假设有就要申请线程变量（或者加锁），否则必定出core。

不要给自己埋下一个坑：

今天一个同学的core看起来是做了一个“优化”，节省了申请变量的时间。

void init() {
    my_struct * some_var;
    ...
    some_var->res = new some_res;
    some_var->res->set_value1(some_common_value1);
    some_var->res->set_value2(some_common_value2);
}

void * thread_func(my_struct * some_var) {
     
    some_var->res->set_value3(value_3);
   ...
}