澳门新葡萄京官网首页如何提高 Java 中锁的性能

两个月前向Plumbr公司引进线程死锁的检测之后,我们开始收到一些类似于这样的询问:“棒极了!现在我知道造成程序出现性能问题的原因了,但是接下来该怎么做呢?”

锁不是问题的根源,锁之间的竞争才是

通常在多线程的代码中遇到性能方面的问题时,一般都会抱怨是锁的问题。毕竟锁会降低程序的运行速度和其较低的扩展性是众所周知的。因此,如果带着这种“常识”开始优化代码,其结果很有可能是在之后会出现讨人厌的并发问题。

因此,明白竞争锁和非竞争锁的不同是非常重要的。当一个线程试图进入
另一个线程正在执行的同步块或方法时会触发锁竞争。该线程会被强制进入等待状态,直到第一个线程执行完同步块并且已经释放了监视器。当同一时间只有一个线
程尝试执行同步的代码区域时,锁会保持非竞争的状态。

事实上,在非竞争的情况下和大多数的应用中,JVM已经对同步进行了优化。非竞争锁在执行过程中不会带来任何额外的开销。因此,你不应该因为性能问题抱怨锁,应该抱怨的是锁的竞争。当有了这个认识之后,让我们来看下能做些什么,以降低竞争的可能性或减少竞争的持续时间。

【JAVA并发】同步容器和并发容器,java并发同步容器

我们努力为自己的产品所遇到的问题思考解决办法,但在这篇文章中我将给大家分享几种常用的技术,包括分离锁、并行数据结构、保护数据而非代码、缩小锁的作用范围,这几种技术可以使我们不使用任何工具来检测死锁。

保护数据而非代码

解决线程安全问题的一个快速的方法就是对整个方法的可访问性加锁。例如下面这个例子,试图通过这种方法来建立一个在线扑克游戏服务器:

class GameServer {
  public Map<<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      if (tablePlayers.size() < 9) {
        tablePlayers.add(player);
      }
    }
  }
  public synchronized void leave(Player player, Table table) {/*body skipped for brevity*/}
  public synchronized void createTable() {/*body skipped for brevity*/}
  public synchronized void destroyTable(Table table) {/*body skipped for brevity*/}
}

作者的意图是好的——当一个新的玩家加入牌桌
时,必须确保牌桌上的玩家个数不会超过牌桌可以容纳的玩家总个数9。

但是这种解决办法事实上无论何时都要对玩家进入牌桌进行控制——即使是在服务器的访问量较小的时候也是这样,那些等
待锁释放的线程注定会频繁的触发系统的竞争事件。包含对账户余额和牌桌限制检查的锁定块很可能大幅提高调用操作的开销,而这无疑会增加竞争的可能性和持续
时间。

解决的第一步就是确保我们保护的是数据,而不是从方法声明移到方法体中的那段同步声明。对于上面那个简单的例子来说,可能改变不大。但是我们要站在整个游戏服务的接口之上来考虑,而不是单单的一个join()方法。

class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    synchronized (tables) {
      if (player.getAccountBalance() > table.getLimit()) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  public void leave(Player player, Table table) {/* body skipped for brevity */}
  public void createTable() {/* body skipped for brevity */}
  public void destroyTable(Table table) {/* body skipped for brevity */}
}

原本可能只是一个小小的改变,影响的可是整个类的行为方式。玩家无论何时加入牌桌,先前的同步方法都会对整个GameServer实例加锁,进而会与那些同时试图离开牌桌的玩家产生竞争。将锁从方法声明移到方法体中会延迟锁的加载,进而降低了锁竞争的可能性。

同步容器类

锁不是问题的根源,锁之间的竞争才是

通常在多线程的代码中遇到性能方面的问题时,一般都会抱怨是锁的问题。毕竟锁会降低程序的运行速度和其较低的扩展性是众所周知的。因此,如果带着这种“常识”开始优化代码,其结果很有可能是在之后会出现讨人厌的并发问题。

因此,明白竞争锁和非竞争锁的不同是非常重要的。当一个线程试图进入
另一个线程正在执行的同步块或方法时会触发锁竞争。该线程会被强制进入等待状态,直到第一个线程执行完同步块并且已经释放了监视器。当同一时间只有一个线
程尝试执行同步的代码区域时,锁会保持非竞争的状态。

事实上,在非竞争的情况下和大多数的应用中,JVM已经对同步进行了优化。非竞争锁在执行过程中不会带来任何额外的开销。因此,你不应该因为性能问题抱怨锁,应该抱怨的是锁的竞争。当有了这个认识之后,让我们来看下能做些什么,以降低竞争的可能性或减少竞争的持续时间。

缩小锁的作用范围

现在,当确信了需要保护的是数据而非程序后,我们应该确保我们只在必要的地方加锁——例如当上面的代码被重构之后:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      synchronized (tables) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

这样那段包含对玩家账号余额检测(可能引发IO操作)的可能引起费时操作的代码,被移到了锁控制的范围之外。注意,现在锁仅仅被用来防止玩家人数超过桌子可容纳的人数,对账户余额的检查不再是该保护措施的一部分了。

同步容器类的创建

在早期的JDK中,有两种现成的实现,Vector和Hashtable,可以直接new对象获取;

在JDK1.2中,引入了同步封装类,可以由Collections.synchronizedXxxx等方法创建;

保护数据而非代码

解决线程安全问题的一个快速的方法就是对整个方法的可访问性加锁。例如下面这个例子,试图通过这种方法来建立一个在线扑克游戏服务器:

class GameServer {
  public Map<<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      if (tablePlayers.size() < 9) {
        tablePlayers.add(player);
      }
    }
  }
  public synchronized void leave(Player player, Table table) {/*body skipped for brevity*/}
  public synchronized void createTable() {/*body skipped for brevity*/}
  public synchronized void destroyTable(Table table) {/*body skipped for brevity*/}
}

作者的意图是好的——当一个新的玩家加入牌桌
时,必须确保牌桌上的玩家个数不会超过牌桌可以容纳的玩家总个数9。

但是这种解决办法事实上无论何时都要对玩家进入牌桌进行控制——即使是在服务器的访问量较小的时候也是这样,那些等
待锁释放的线程注定会频繁的触发系统的竞争事件。包含对账户余额和牌桌限制检查的锁定块很可能大幅提高调用操作的开销,而这无疑会增加竞争的可能性和持续
时间。

解决的第一步就是确保我们保护的是数据,而不是从方法声明移到方法体中的那段同步声明。对于上面那个简单的例子来说,可能改变不大。但是我们要站在整个游戏服务的接口之上来考虑,而不是单单的一个join()方法。

class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    synchronized (tables) {
      if (player.getAccountBalance() > table.getLimit()) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  public void leave(Player player, Table table) {/* body skipped for brevity */}
  public void createTable() {/* body skipped for brevity */}
  public void destroyTable(Table table) {/* body skipped for brevity */}
}

原本可能只是一个小小的改变,影响的可是整个类的行为方式。玩家无论何时加入牌桌,先前的同步方法都会对整个GameServer实例加锁,进而会与那些同时试图离开牌桌的玩家产生竞争。将锁从方法声明移到方法体中会延迟锁的加载,进而降低了锁竞争的可能性。

分离锁

你可以从上面例子最后一行代码清楚的看到:整个数据结构是由相同的锁保护着。考虑到在这一种数据结构中可能会有数以千计的牌桌,而我们必须保护任何一张牌桌的人数不超过容量,在这样的情况下仍然会有很高的风险出现竞争事件。

关于这个有一个简单的办法,就是对每一张牌桌引入分离锁,如下面这个例子所示:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      synchronized (tablePlayers) {
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

现在,我们只对单一牌桌的可访问性进行同步而不是所有的牌桌,这样就显著降低了出现锁竞争的可能性。举一个具体的例子,现在在我们的数据结构中有100个牌桌的实例,那么现在发生竞争的可能性就会比之前小100倍。

同步容器类的问题

同步容器类虽然都是线程安全的,但是在某些情况下(复合操作),仍然需要加锁来保护;

常见复合操作如下:

举个条件运算的例子,代码如下:

package concurrency.old;

import java.util.Vector;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

//线程任务类,获取集合中的最后一个元素
class GetLast implements Runnable{

    private Vector<Integer> list;

    public GetLast(Vector<Integer> list) {
        this.list = list;
    }
    @Override
    public void run() {
        while(true){
            try{
                Test.getLast(list);
            }catch(Exception e){
                e.printStackTrace();
                System.out.println(e.getMessage() + " --- in class GetLast");
                break;
            }

        }

    }

}
//线程任务类,删除&添加元素
class DeleteAndAdd implements Runnable{

    private Vector<Integer> list;

    public DeleteAndAdd(Vector<Integer> list) {
        this.list = list;
    }
    @Override
    public void run() {
        while(true){
            try{
                Test.deleteAndAdd(list);
            }catch(Exception e){
                e.printStackTrace();
                System.out.println(e.getMessage() + " --- in class DeleteAndAdd");
                break;
            }

        }

    }

}

public class Test {

    //获取最后一个元素
    public static  Integer getLast(Vector<Integer> list){
        //这里根据list.size()得到最后一个元素的索引
        //换句话说,这条语句已经检查认为在集合list中存在索引为list.size() - 1的元素
        int lastIndex = list.size() - 1;

        if(lastIndex < 0) return null;

        //返回指定索引处的元素
        return list.get(lastIndex);
    }

    //删除元素,添加元素
    public static  void deleteAndAdd(Vector<Integer> list){
        int lastIndex = list.size() - 1;
        if(lastIndex < 0) return;
        list.remove(lastIndex);
        list.add(3);
    }

    public static void main(String[] args) {
        Vector<Integer> vector = new Vector<Integer>();
        vector.add(1);
        vector.add(2);

        ExecutorService exec = Executors.newCachedThreadPool();

        GetLast gl = new GetLast(vector);
        DeleteAndAdd daa = new DeleteAndAdd(vector);

        exec.execute(gl);
        exec.execute(daa);

    }
}

运行以上程序,很快发现在getLast中抛出了java.lang.ArrayIndexOutOfBoundsException异常,原因在于getLast方法不是原子操作,调用size方法和get方法之间,其它线程执行了remove操作,导致容器大小变小,索引访问越界,抛出异常。

若想得到正确结果,可修改代码,对getLast和deleteAndAdd方法里的操作加锁(因为Vector内部是通过自身对象作为锁的,所以这里同样以Vector对象作为锁),使之成为原子操作,如下代码:

    //获取最后一个元素
    public static  Integer getLast(Vector<Integer> list){
        synchronized(list){
            //这里根据list.size()得到最后一个元素的索引
            //换句话说,这条语句已经检查认为在容器list中存在索引为list.size() - 1的元素
            int lastIndex = list.size() - 1;

            if(lastIndex < 0) return null;

            //返回指定索引处的元素
            return list.get(lastIndex);
        }
    }

    //删除元素,添加元素
    public static  void deleteAndAdd(Vector<Integer> list){
        synchronized(list){
            int lastIndex = list.size() - 1;
            if(lastIndex < 0) return;
            list.remove(lastIndex);
            list.add(3);
        }
    }

另外,在对vector的元素遍历时(for循环方式),其它线程删除了容器中的一个元素,也会抛出异常java.lang.ArrayIndexOutOfBoundsException异常,原因与上面提到的getLast方法一样,在访问最后一个元素的时候越界了;

        for(int i = 0; i < vector.size(); i++){
            System.out.println(vector.get(i));
        }

一个可行的修改方式同样是对容器加锁,但代价较大,导致其它线程在迭代期间不能访问容器,降低了并发性;

        synchronized(vector){
            for(int i = 0; i < vector.size(); i++){
                System.out.println(vector.get(i));
            }
        }

缩小锁的作用范围

现在,当确信了需要保护的是数据而非程序后,我们应该确保我们只在必要的地方加锁——例如当上面的代码被重构之后:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      synchronized (tables) {
        List<Player> tablePlayers = tables.get(table.getId());
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

这样那段包含对玩家账号余额检测(可能引发IO操作)的可能引起费时操作的代码,被移到了锁控制的范围之外。注意,现在锁仅仅被用来防止玩家人数超过桌子可容纳的人数,对账户余额的检查不再是该保护措施的一部分了。

使用线程安全的数据结构

另一个可以改善的地方就是抛弃传统的单线程数据结构,改用被明确设计为线程安全的数据结构。例如,当采用ConcurrentHashMap来储存你的牌桌实例时,代码可能像下面这样:

public class GameServer {
  public Map<String, List<Player>> tables = new ConcurrentHashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {/*Method body skipped for brevity*/}
  public synchronized void leave(Player player, Table table) {/*Method body skipped for brevity*/}

  public synchronized void createTable() {
    Table table = new Table();
    tables.put(table.getId(), table);
  }

  public synchronized void destroyTable(Table table) {
    tables.remove(table.getId());
  }
}

在join()和leave()方法内部的同步块仍然和先前的例子一样,因为我们要保证单个牌桌数据的完整性。ConcurrentHashMap
在这点上并没有任何帮助。但我们仍然会在increateTable()和destoryTable()方法中使用ConcurrentHashMap创建和销毁新的牌桌,所有这些操作对于ConcurrentHashMap来说是完全同步的,其允许我们以并行的方式添加或减少牌桌的数量。

 迭代器及快速失败机制

同步容器与非同步容器一样,在迭代期间,若其它线程并发修改该容器,会抛出ConcurrentModificationException异常,即快速失败机制,之前有写过相关内容,详见下面链接:

通过在容器迭代期间对容器加锁来解决该问题是一种方式,但并发性差,当容器规模大时,更加严重,而且还可能产生死锁问题;一种更优的解决方式,如上面链接里提到的,采用克隆容器(CopyOnWriteArrayList等),在副本上进行操作,但存在显著的性能开销,需要拷贝数组等操作,这种方式的好坏要看具体需求,如容器大小,执行的具体操作,调用频率等,一般当迭代操作远多于修改操作时,比较适用克隆容器;

另外,在集合中,有一些隐藏的迭代操作,如toString,equals,hashCode等方法,使用时需注意,也可能会抛出ConcurrentModificationException异常;

分离锁

你可以从上面例子最后一行代码清楚的看到:整个数据结构是由相同的锁保护着。考虑到在这一种数据结构中可能会有数以千计的牌桌,而我们必须保护任何一张牌桌的人数不超过容量,在这样的情况下仍然会有很高的风险出现竞争事件。

关于这个有一个简单的办法,就是对每一张牌桌引入分离锁,如下面这个例子所示:

public class GameServer {
  public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();

  public void join(Player player, Table table) {
    if (player.getAccountBalance() > table.getLimit()) {
      List<Player> tablePlayers = tables.get(table.getId());
      synchronized (tablePlayers) {
        if (tablePlayers.size() < 9) {
          tablePlayers.add(player);
        }
      }
    }
  }
  //other methods skipped for brevity
}

现在,我们只对单一牌桌的可访问性进行同步而不是所有的牌桌,这样就显著降低了出现锁竞争的可能性。举一个具体的例子,现在在我们的数据结构中有100个牌桌的实例,那么现在发生竞争的可能性就会比之前小100倍。

其他一些建议和技巧

  • 降低锁的可见度。在上面的例子中,锁被声明为public(对外可见),这可能会使得一些别有用心的人通过在你精心设计的监视器上加锁来破坏你的工作。
  • 通过查看java.util.concurrent.locks 的API来看一下
    有没有其它已经实现的锁策略,使用其改进上面的解决方案。
  • 使用原子操作。在上面正在使用的简单递增计数器实际上并不要求加锁。上面的例子中更适合使用
    AtomicInteger代替Integer作为计数器。

最后一点,无论你是否正在使用Plumber的自动死锁检测解决方案,还是手动从线程转储获得解决办法的信息,都希望这篇文章可以为你解决锁竞争的问题带来帮助。

  

  

  

  

并发容器

同步容器对所有容器状态的访问都串行化,严重降低了并发性;当多个线程竞争锁时,吞吐量严重下降;

java5.0之后提供了多种并发容器来改善同步容器的性能,如ConcurrentHashMap、CopyOnWriteArrayList、CopyOnWriteArraySet、ConcurrentSkipListMap等;

这里主要看下ConcurrentHashMap;

使用线程安全的数据结构

另一个可以改善的地方就是抛弃传统的单线程数据结构,改用被明确设计为线程安全的数据结构。例如,当采用ConcurrentHashMap来储存你的牌桌实例时,代码可能像下面这样:

public class GameServer {
  public Map<String, List<Player>> tables = new ConcurrentHashMap<String, List<Player>>();

  public synchronized void join(Player player, Table table) {/*Method body skipped for brevity*/}
  public synchronized void leave(Player player, Table table) {/*Method body skipped for brevity*/}

  public synchronized void createTable() {
    Table table = new Table();
    tables.put(table.getId(), table);
  }

  public synchronized void destroyTable(Table table) {
    tables.remove(table.getId());
  }
}

在join()和leave()方法内部的同步块仍然和先前的例子一样,因为我们要保证单个牌桌数据的完整性。ConcurrentHashMap
在这点上并没有任何帮助。但我们仍然会在increateTable()destoryTable()方法中使用ConcurrentHashMap创建和销毁新的牌桌,所有这些操作对于ConcurrentHashMap来说是完全同步的,其允许我们以并行的方式添加或减少牌桌的数量。

ConcurrentHashMap

采用分离锁技术,同步容器中,是一个容器一个锁,但在ConcurrentHashMap中,会将hash表的数组部分分成若干段,每段维护一个锁,以达到高效的并发访问;

迭代器弱一致性,迭代期间不会抛出ConcurrentModificationException异常;

size()、isEmpty()等方法返回的是一个近似值;

增加了若干原子操作方法,如putIfAbsent(没有改key,则添加);

同步容器类 同步容器类的创建
在早期的JDK中,有两种现成的实现,Vector和Hashtable,可…

其他一些建议和技巧

  • 降低锁的可见度。在上面的例子中,锁被声明为public(对外可见),这可能会使得一些别有用心的人通过在你精心设计的监视器上加锁来破坏你的工作。
  • 通过查看java.util.concurrent.locks 的API来看一下
    有没有其它已经实现的锁策略,使用其改进上面的解决方案。
  • 使用原子操作。在上面正在使用的简单递增计数器实际上并不要求加锁。上面的例子中更适合使用
    AtomicInteger代替Integer作为计数器。

最后一点,无论你是否正在使用Plumber的自动死锁检测解决方案,还是手动从线程转储获得解决办法的信息,都希望这篇文章可以为你解决锁竞争的问题带来帮助。

发表评论

电子邮件地址不会被公开。 必填项已用*标注