这看似一个很小的改动，却会影响到整个类的行为。当玩家加入牌桌 时，前面那个同步的方法会锁在GameServer的this实例上，并与同时想离开牌桌(leave)的玩家产生竞争行为。而将锁从方法签名移到方法内部以后，则将上锁的时机往后推迟了，一定程度上减小了竞争的可能性。
　　缩小锁的作用域
　　现在我们已经确保保护的是数据而不是代码了，我们得再确认锁住的部分都是必要的——比如说，代码可以重写成这样 ：

 

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
}

　　现在检查玩家余额的这个耗时操作在锁作用域外边了。注意到了吧，锁的引入其实只是为了保护玩家数量不超过桌子的容量而已，检查帐户余额这个事情并不在要保护的范围之内。
　　分拆锁
　　再看下上面这段代码，你会注意到整个数据结构都被同一个锁保护起来了。考虑到这个数据结构中可能会存有上千张牌桌，出现竞争的概率还是非常高的，因此保护每张牌桌不超出容量的工作好能分别来进行。
　　对于这个例子而言，为每张桌子分配一个独立的锁并非难事，代码如下：

 

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倍。
　　使用并发的数据结构
　　另一个可以改进的地方是弃用传统的单线程的数据结构，改为使用专门为并发所设计的数据结构。比如说，可以用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()方法的同步操作变得更简单了，因为我们现在不用再对tables进行加锁了，这都多亏了ConcurrentHashMap。然而，我们还是要保证每个tablePlayers的一致性。因此这个地方ConcurrentHashMap帮不上什么忙。同时我们还得在createTable()与destroyTable()方法中创建新的桌子以及销毁桌子，这对ConcurrentHashMap而言本身是并发的，因此你可以并行地增加或者减少桌子的数量。
　　其它的技巧及方法
　　降低锁的可见性。在上述例子中，锁是声明为public的，因此可以被别人所访问到，你所精心设计的监视器可能会被别人锁住，从而功亏一篑。
　　看一下java.util.concurrent.locks包下面有哪些锁策略对你是有帮助的。
　　使用原子操作。上面这个例子中的简单的计数器其实并不需要进行加锁。将计数的Integer换成AtomicInteger对这个场景来说绰绰有余了。