使用场景
对底层代码进行 HOOK, 不可避免的要考虑多线程同步问题， 当然也可以写个类似 java 的线程本地变量来隔离内存空间。
死锁分析
恩， 道理其实大家都懂的， 毕竟大学就学了操作系统，理论神马的窝就不讲了哈， 这里说说我的处理方法。首先线程同步问题主要是多线程对相同的可写内存进行操作导致的， 辣么我们给这些可写的内存，每个内存都加把锁不就得了， 哈哈，就这么简单， 我们将存在多个线程访问的一块内存（比如说一个变量， 一个结构体，一个类）都配把锁， 这样确实就解决线程同步问题了， 但是作为一只程序员，必须打起12分的精神，时刻小心自己是否会掉坑里面去，这里也是哦， 如果按上面这么做，确实解决了多线程数据不一致问题，但是极有可能导致其他问题的出现， 比如死锁， 性能低下等， 当然咱也不需要慌， 上面的设计思路是正确的（可写的多线程共享内存加锁），我们可以添加一些规范来规避这些问题；要想解决一个问题， 我们必须能够知道这个问题发生的原因是什么
死锁的简介：
线程A1， A2， 资源 R1， R2， 对应锁 RL1， RL2
A1的某个操作需要RL1， RL2
A2的某个操作需要RL2， RL1
说明： A1在获取RL2锁的时候阻塞了， A2在获取RL1锁的时候阻塞了
RL1 RL2
A 1--------------R1-------x------R2
RL2 RL1
A2 --------------R2-------x-------R1
嘛， 重上面的分析知道，产生死锁的条件有这些：（窝的看法， 理论的说法请自行百度）
存在两个以上的锁（这是理所当然的啦， 如果只有一个锁，肿么可能存在死锁问题QAQ, 所以如果多线程共用一个锁，那就大胆的使用， 不用担心死锁啦）线程获取锁的顺序不一致, 理论一点的说法就是资源存在环形链(可以这么说，如果有多个锁， 但是所有的获得锁的顺序是一样的，那么这些锁其实等价于一个锁， 多块内存也可以看做一个大内存啦， 这个可以用反证法证明)
如何解决死锁
我的处理方法是这样的（各位大佬有更好的想法求评论区@）
减少锁嵌套， 也就是临界区的代码量尽量小， 尽量代码分开加锁，比如一个方法可能头部几行代码需要加锁， 和结束的几行需要加同一个锁， 我们就不要将整个方法加锁了， 而是开头加锁，在结尾也加锁， 因为其他代码也有可能加锁了，如果方法整个加锁，辣么锁嵌套就没办法避免了
不要有循环锁的存在， 比如保持所有锁的获取顺序是相同的，辣么就不会有环路等待的条件啦（我在jni代码里面就是这么处理的）
linux 互斥锁
嘛，互斥锁的主要作用是为了让代码进入临界区， 让一段代码可以成为原子操作， 理论上将这个功能只能由操作系统提供， 毕竟操作系统负责任务调度， 管理中断信息， 在 Java 和c++11 中都直接提供了api，c++11 中是 std::mutex, 然而我的 ndk 环境并没有这个 api,所以就用了 linux 系统里面的 api 来实现了。
互斥锁
（互斥锁 = synchronized）
API说明
//数据结构：
pthread_mutex_t
// 行为：
// 初始化：
// 静态初始化：
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
// 动态初始化：
int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutex_attr_t *mutexattr);
// 获得锁：
int pthread_mutex_lock(pthread_mutex *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
// 释放锁：
int pthread_mutex_unlock(pthread_mutex_t *mutex);
// 销毁锁：
int pthread_mutex_destroy(pthread_mutex *mutex);
// 以上可以发现命名规律， 文件名前缀_抽象的工能名_具体事务
// 嘛，写c程序的话可以这么命名， 用c++的就不必啦
使用说明
初始化----加锁--------释放锁------销毁锁
下面是我在ndk中封装的Lock
//SimpleLock.h;
class SimpleLock
{
public :
SimpleLock();
void lock();
void unlock();
~SimpleLockl();
private:
pthread_mutex_t __m;
}
//SimpleLock.cpp
SimpleLock::SimpleLock()
{
__m = (pthread_mutex_t)PTHREAD_MUTEX_INITIALIZER;
}
void SimpleLock::lock()
{
int ret = pthread_mutex_lock(&__m);
assert(ret == 0);
}
void SimpleLock::unlock()
{
int ret = pthread_mutex_unlock(&__m);
assert(ret == 0);
}
SimpleLock::~SimpleLock()
{
pthread_mutex_destory(&__m);
}
特别注意
这里的加锁和解锁应该配对，应该配对，应该配对（重要的事情要说三变） ,最后不用了应该销毁， 应为这部分内存是没办法回收的， 所以说不用的时候要销毁掉，嘛，这里就写到析构函数里面啦， 如果是 c 写的...（额， 别忘了就好）
bug: 探针的获取ndk数据代码里面也是加了锁的，然而正常情况下没啥问题，如果数据有错， 该方法会直接返回， 但是返回的时候没有解锁！！！最后第二次获取数据的时候程序无响应了！！！
条件锁
（本来只想将总结互斥锁，但是条件锁很好玩，也就顺带看一下啦）
//嘛， 条件锁的作用我理解的就是linux给我们实现的一个简单的观察者。
// 主要结构：
// 数据结构：
pthread_cond_t cond_lock;
// 初始化：
// 静态：
PTHREAD_COND_INITIALIZER
// 动态:
int pthread_cond_init(pthread_cond_t *cv,const pthread_condattr_t *cattr)
// 行为：
// 等待：
int pthread_cond_wait(pthread_cond_t *cv,pthread_mutex_t *mutex);
// 通知:
int pthread_cond_signal(pthread_cond_t *cv);
使用场景
在临界区中某个因为满足某个条件而阻塞， 又应为某个条件满足而被唤醒，主要是如果不用条件锁， 如果某个线程需要特定条件才能执行， 而这个条件依赖去其他线程， 那么就要让这个线程隔一段时间查询一下状态，满足则执 行，否则阻塞，这样会导致性能问题， 所以条件锁可以在状态满足条件的时候通知阻塞的线程执行。而且一般来说条件锁和互斥锁要一起用。
pthread_mutex_t m;
pthread_cond_t c;
线程一：
pthread_mutex_lock(&m);
if (条件不满足)
{
pthread_cond_wait(&c, &m);//等待状态满足后再执行
}
pthread_mutex_unlock(&m);
线程二:
pthread_mutex_lock(&m);
...
if (条件满足) //线程一可以执行了
{
pthread_cond_signal(&c);
}
...
pthread_mutex_unlock(&m);