##linux系统的同步机制
- 信号量
- 锁
##死锁
线程A需要资源X，而线程B需要资源Y，而双方都掌握有对方所要的资源，这种情况称为死锁（deadlock），或死亡拥抱（the deadly embrace）。
在并发程序设计中，死锁 (deadlock) 是一种十分常见的逻辑错误。通过采用正确的编程方式，死锁的发生不难避免。
###死锁的四个必要条件
死锁的四个必要条件，这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。
- 互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；
- 持有（Hold and wait）：当请求的资源已被占用从而导致执行程序阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；
- 不可剥夺（No preemption）：执行程序获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；
- 环形等待（Circular wait）：若干执行程序以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行程序组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。
###解除死锁的必要条件
不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁操作均作为事务对待，一旦开始上锁，即确保全部操作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。
消除第四项条件是比较容易且代价较低的办法。具体来说这种方法约定：上锁的顺序必须一致。具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。无论已持有任何锁，该执行者所有的上锁操作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。
请注意，放锁的顺序并不会导致死锁。也就是说，尽管按照 锁A, 锁B, 放A, 放B 这样的顺序来进行锁操作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。
##解决方法：
- 使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务； (细化处理逻辑，执行一段逻辑后便回滚或者提交，然后再执行其它逻辑，直到事物执行完毕提交)
- 设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；