各种死锁,性能和测试

加一堆锁也许能保证线程安全, 但是却可能造成死锁

数据库服务器避免死锁的方式

1. 发现死锁;
2. 选择一个牺牲者, 退出事务;
3. 程序继续运行.

jvm解决死锁的方式

1. 这些线程直接不能用....恢复的唯一方式是终止并重启, 然后寄希望于不要再发生同样的事.

锁顺序死锁

如果所有线程通过固定顺序获取多个锁, 程序就不会出现锁顺序死锁

//警告: 易发生死锁
public class LeftRightDeadLock{
    private final Object left = new Object();
    private final Object right = new Object();
    
    public void leftRight(){
        synchronized(left){
                sychronized(right){
                    //do some thing
                }
        }
    }
    public void rightLeft(){
        synchronized(right){
                sychronized(left){
                    //do some thing
                }
        }
    }
}

LeftRightDeadLock的偶发时序

下面的顺序死锁不那么一目了然

//警告:易产生死锁
public void transferMoney(Account fromAccount,Account toAccount,DollarAmount amount) throws InsufficientFundsException {
    synchronized(fromAccount){    //同时向对方转账时, from 和 to两个账户存在死锁风险
        synchronized(toAccount){
             if(fromAccount.getBalance().compareTo(amount)<0)
                  throw new InsufficientFundsException ();
            else{
               fromAccount.debit(amount);
               toAccount.credit(amount);
            }
        }
    }
}

解决方法

制定锁的顺序 并且整个应用中,获取锁必须遵守这个顺序

下面用对象hashcode决定锁顺序, (hash冲突仍然存在死锁风险, 此时用竞争机制保证锁定)

private static final Object tieLock = new Object();//"加时赛"锁, 谁先拿到,谁就先执行

public void transferMoney(Account fromAccount,Account toAccount,DollarAmount amount) throws InsufficientFundsException {
    class Helper{
        public void transfer() throws InsufficientFundsException {
             if(fromAccount.getBalance().compareTo(amount)<0)
                  throw new InsufficientFundsException ();
            else{
               fromAccount.debit(amount);
               toAccount.credit(amount);
        }
    }
    int fromHash = System.identityHashCode(fromAccount)
    int toHash = System.identityHashCode(toAccount)
    if(fromHash < toHash){//如果from的hashcode小, 则先锁from
        synchronized(fromAccount){    
            synchronized(toAccount){
                 new Helper().transfer();
            }
        }
    }else if(fromHash > toHash){//如果to的hashcode小, 则先锁to对象
        synchronized(toAccount){    
            synchronized(fromAccount){
                 new Helper().transfer();
            }
        }
    }else{ //如果两个对象hash相同, 则锁住整个转账对象. 一次只让一个人转
        synchronized(tieLock){
            synchronized(fromAccount){    
                synchronized(toAccount){
                     new Helper().transfer();
                }
            }
        }
    }
}

加时赛锁有代替方案: 如果账号有唯一属性, 比如账号id是唯一的, 那么直接比较账号id即可. 这样可以节省加时赛锁

协作对象间的死锁

//警告: 可能产生死锁
class Taxi {
    @GuardedBy("this)
    private Point location,destination;
    private final Dispatcher dispatcher;
    
    public Taxi(Dispatcher dispatcher){
        this.dispatcher
    }
}

总结一下常见的多线程危险

1. 死锁
2. 饥饿

一个线程占着资源, 其他线程很久都等不到锁

3. 丢失信号

    就是在等锁的时候,别人放开锁的消息丢了,,,导致线程一直等下去了...

4. 活锁

    线程没死, 但是拿不到资源, 就不停的重试,再重试....卡着无法前进...解决办法是做一些随机, 相互避让.

java 线程api的优先级仅仅是一种参考, 具体级别取决于系统的优先级.
另外又容易导致某个线程优先级永远高于其他线程而导致饥饿

所以: 尽量不要去改变线程优先级

一旦开始改变线程优先级, 则程序的行为就变成平台相关了.并且会引入饥饿的风险