只要你写过比较复杂的 C++ 项目，应该都或多或少遇见过进程 Coredump 的问题。Coredump 是程序运行过程中发生严重错误时，操作系统将程序当前的内存状态记录下来的一种机制。

C++ 中导致进程 Coredump 的原因有很多，比如：

1. 访问非法内存地址：包括空指针解引用、访问已释放的内存、数组越界访问等；
2. 栈溢出：无限递归、大数组分配在栈上；
3. 段错误（Segmentation Fault）：试图写入只读内存、访问未映射的内存区域；
4. 异常未捕获：未处理的异常导致程序终止；

遇到 Coredump 问题时，一般需要打开 core 文件，然后根据 core 文件来进行问题分析和调试。分析 core 文件有时候还是比较难的，需要对 C++ 的内存模型、异常处理机制、系统调用等有深入的理解。

本文不会过多介绍分析 core 文件的方法，而是通过几个真实项目中的案例，来让大家在写代码时候，能够有意识地避免这些错误。

LevelDB 中有一些宏比较有意思，平时自己写代码的时候，还基本没用过。这些宏在 thread_annotations.h 中定义，可以在编译时使用 Clang 编译器的线程安全分析工具，来检测潜在的线程安全问题。

Clang 编译器的线程安全分析工具

哈希表(HashTable) 是一个经典的数据结构，只要写点过代码，应该都有用过哈希表。每种语言都有自己的哈希表实现，基本都是开箱即用。以至于虽然用过哈希表的人很多，但自己动手写过哈希表的人估计没多少吧。

要设计一个高性能的哈希表，其实还是有不少细节需要考虑的。比如如何处理哈希冲突，如何处理哈希表扩容等。一些成熟的哈希表实现，比如 C++ 标准库中的哈希表，代码量比较大，也比较难理解。

好在 LevelDB 在实现 LRU Cache 的时候，顺便实现了一个简单高效的哈希表，整体代码写的很精简，麻雀虽小五脏俱全，非常值得学习。本文以 LevelDB 的哈希表实现为例，分析下如何设计一个高性能的哈希表。