demo源码：https://github.com/mantuliu/javaAdvance 中的类Lesson4IndependentLock
在上一节中，我们分析了Lock的源代码并一起实践了粗粒度锁对于性能的影响，在本节中，我们将用锁机制来解决一个生产环境实际的案例。下面的案例是一个真实的案例。
之前我在一家移动医疗公司做架构师的时候， 我司有一个主要的业务是通过网络来完成预约挂号的业务，对于下单操作，之前的版本都是各个jvm独立完成，各个服务之间没有依赖，由于号源是非常珍贵的资源，所以就存在黄牛刷号的情况，最后就出现了，同一个用户在同一个时段上挂到了同一个医生两个以上的号。当时由于前端的负载均衡设备是按照iphash策略来进行负载均衡的，因此我给出了第一版的解决方案，使用细粒度的锁来实现(如果这里我们上了粗粒度的锁，也就是所有的线程都要锁同一个资源才能下单，又因为下单的时间比较慢，大家可以想象一下，所有的线程全部卡在了同一个节点上，直接下单服务完全停止服务)，通过业务分析，我们的锁可以定义为预约人和医生的组合，上一节中我们使用了1.5的Lock来实现的锁，本节中我们才用synchronized机制来实现，demo如下：
package com.mantu.advance; import java.util.HashMap; /**
* blog http://www.cnblogs.com/mantu/
* github https://github.com/mantuliu/
* @author mantu
*
*/
public class Lesson4IndependentLock implements Runnable{
String custName;//挂号人姓名
String doctorId;//医生id
String other;//其它附属信息 public static HashMap<String,StringBuffer> orderMap = new HashMap<String,StringBuffer>();//此map中存储的是挂号人和医生的组合信息，也就是我们的细粒度的锁
public static HashMap<String,String> orderYanzhengMap = new HashMap<String,String>();//此map用来存储订单信息 public static void main(String args[]){
for(int i =0;i<3;i++){//每个用户同时启动3个线程
Lesson4IndependentLock lock1 = new Lesson4IndependentLock("王小二", "123456", "test");
new Thread(lock1).start();
Lesson4IndependentLock lock2 = new Lesson4IndependentLock("张小三", "123456", "test");
new Thread(lock2).start();
}
} public Lesson4IndependentLock(String custName,String doctorId,String other){
this.custName=custName;
this.doctorId=doctorId;
this.other=other;
}
//添加订单方法
public void addOrder(String custName,String doctorId,String other){
StringBuffer lockString = null;
if(orderMap.containsKey(custName+"&"+other)){
lockString=orderMap.get(custName+"&"+other);//如果orderMap已经存在后面需要用到的锁信息，则直接取出
}
else{
synchronized(orderMap){//如果没有，则创建一个公用的锁对象，并添加进去，保证所有相关的线程(同一个用户同一个医生)是用同一把锁
if(!orderMap.containsKey(custName+"&"+other)){
lockString = new StringBuffer(custName+"&"+other);
orderMap.put(custName+"&"+other, lockString);
}
else{
lockString=orderMap.get(custName+"&"+other);
}
}
}
synchronized(lockString){//锁定小粒度的挂号人和医生组合信息的锁
if(orderYanzhengMap.containsKey(custName+"&"+other)){//验证
System.out.println(custName+"之前已经下过"+doctorId+"的预约单，不能重复下单");
}
else{
orderYanzhengMap.put(custName+"&"+other, custName+"&"+other);//下单
System.out.println(custName+"刚刚下了一个"+doctorId+"的预约单");
}
}
}
@Override
public void run() {
addOrder(custName,doctorId,other);//下单
}
}
上面的实现方式已经很好地解决了重复下单的问题，但是由于后来我们的负载均衡策略改变了，变成了随机的方式，同一个客户下的多笔单可以随机落到各个服务器上。这时，我们只能采用分布式锁的方案来解决重复下单的问题，对问题进行分析：由于我们锁的粒度很小，是对挂号人和医生联合的对象来上锁，正常情况下的用户操作，用户不可能同时下同一个医生的订单，那么我们的分布式锁就可以模拟高并发包中的trylock()机制，而不必采用阻塞等待的lock()机制，如果发现锁已经被其它线程获取到了，马上放弃并返回失败，demo Lesson4DistributedLock：模拟了分布式做下订单的场景，文中主要是采用了redis的setnx操作，此操作是一个原子操作。