多线程、进程并行访问共享资源时，一定要加锁保护 说明：共享资源包括全局变量，静态变量，共享内存，文件等。 建议封装像智能指针一样的对象对锁进行管理。
锁的职责单一 说明：每个锁只锁一个唯一共享资源；这样，才能保证锁应用的单一，也能更好的确保加锁的范围尽 量小。 对于共享全局资源，应该根据实际需要，每类或每个资源，有一把锁。这样，这把锁只锁对这个资源 访问的代码，通常这样的代码都会是比较简单的资源操作代码，不会是复杂的函数调用等。相反，如 果我们对几类或几个资源共用一把锁。这把锁的责任范围就大了，使用复杂，很难理清锁之间的关系(有 没有释放锁，或者锁之间的嵌套加锁等)，容易导致死锁问题。
锁范围尽量小，只锁对应资源操作代码 说明：使用锁时，尽量减少锁的使用范围。我们使用锁，为了方便，会大范围的加锁，如：直接锁几 个函数调用。这种使用，一方面会导致多线程执行效率的低下，容易变成串行执行；另一方面，容易 出现锁未释放，或者锁的代码中再加锁的场景，最后导致死锁。 所以，对锁操作的最好办法，就是只锁简单资源操作代码。对应资源访问完后，马上释放锁。尽量在 函数内部靠近资源操作的地方加锁而不是靠近线程、函数外部加锁。
避免嵌套加锁，如果必须加锁，务必保证不同地方的加锁顺序是一样的 说明：加上一把锁之后，在释放之前，不能再加锁。 典型的锁中加锁的场景：OMU代码中对几个容器的同时遍历，每个容器一把锁，就导致需要加多把锁。 这种场景的解决方法：先加一把锁，对一个容器遍历，选择出合乎要求的数据，并保存在临时变量中； 再加另一把锁，使用临时变量，再对其他容器遍历。 锁中加锁，必须保证加锁的顺序是一样的，比如先加的锁后解锁， Lock1 Lock2 Unlock2 Unlock1 则其他地方的加锁顺序，必须与这里的顺序一样，避免死锁，不允许出现： lock2 lock1 unlock2 unlock1
进程间通讯，使用自己保证互斥的数据库系统、共享内存，或socket消息机制；尽量避免使 用文件等进程无法管理的资源 说明：由于文件在不同进程间访问，无法保证互斥。当然，可以在进程间加进程锁，但只受限于我们 能加锁的进程，对于第三方进程等无法保证。这样，当多个进程同时对文件进行写操作时，将会导致 文件数据破坏，或文件写失败等问题。 当数据库系统本身的访问接口带有互斥机制，当多个进程同时访问时，可以保证数据库数据的完整。 共享内存，只限制于使用共享内存的几个进程，需要我们对这些访问共享内存的进程加锁。但由于共 享内存，第三方进程等无法访问，这也能比较好的保护数据，避免文件系统存在的问题。 socket消息机制，由操作系统socket通讯机制保证互斥，在多个进程间，通过消息来保证数据的互斥。 进程的消息都是操作系统转发而来的独立数据，属于进程私有数据，不存在进程间并行访问的问题。
可重入函数尽量只使用局部变量和函数参数，少用全局变量、静态变量 说明：支持多线程并行访问的函数称之为可重入函数。设计可重入函数时，尽量使用局部变量和函数 参数来传递数据，在多线程并行访问时，互相之间不会受影响。相反，如果使用全局变量、静态变量， 就需要同步。 引申：一些库函数也是非线程安全，调用时可能会出现多线程并发访问问题。
锁中避免调用函数；如果必须调用函数，务必保证不会造成死锁 说明：这条规则是对加锁范围尽量小(只锁对应资源操作代码)规则的补充。不能把调用函数也加到加 锁范围中。因为被调用函数的内部到底做了什么事情，是如何做的，调用者可能不是很清楚。尤其是 当被调用函数内部又加锁的情况，就容易导致两个锁互饿，导致死锁。因为我们调用函数，很多时候只关注函数实现的功能 ，而忽略函数内部的具体实现。 其次，锁中调用函数，也会把对资源操作的代码扩大化，不利于并行效率。更主要的是，这种操作， 由于加锁的范围变大，引起死锁的可能就增大。
锁中避免使用跳转语句 说明：跳转语句包含return、break、continue、goto等。如果锁中有宏调用的代码，要特别注意，分 析宏中是否存在隐含的跳转语句。 在函数返回时忘记把锁释放，特别是存在很多分支都可能返回的时候，可能一些分支会忘记释放锁。
Linux c++线程同步的四种方式：互斥锁，条件变量，读写锁，信号量
