为分布式做准备吧——JVM线程资源同步及交互机制

Java程序采用多线程来支持大量并发。尤其是在多核或者多CPU系统中，多线程执行程序带来的最明显的问题是线程之间同步管理的资源竞争以及线程交互的问题。

JVM的线程实现及其调度方式（抢占、协作）取决于操作系统，不在本文赘述。

线程资源同步机制

有如下程序：

int i=0;
public int getNextId(){
	return i++;
}

以上程序在JVM中执行的步骤如下：
（1） JVM在堆中给i分配一个内存存储场所（main memory），并存储其值为1。
（2） 线程启动后，自动分配一片操作数栈(working memory)，当线程执行到return i++时，JVM的动作分为以下五步：

1. 装载i
   向main memory发起read i指令。
   当read i执行完毕，线程会将i的值从main memory复制到working memory中。
2. 读取i
   从main memory中读取i。
3. 进行i+1操作
   由线程完成。
4. 存储i
   将i+1的值赋值给i，然后存储到working memory中。
5. 写入i
   将i的值回写到main memory中。

从以上步骤中不难发现，从working memory到main memory的存取是需要时间的（反过来也是）；i++是由多个操作完成的（读取 自增 存储），如果是多线程，就会出现脏读、误读等现象。

对于多线程的脏读、误读等现象，JVM把对于working memory的操作分为了use、assign、load、store、lock和unlock。
对于main memory操作分为了read、write、lock和unlock。
不难理解lock和unlock就是锁的使用。对此，JVM提供了synchronized关键字、volatile关键字和lock/unlock机制。

采用synchronized改造如下：

public synchronized int getNextId(){
	return i++;
}

对于lock/unlock机制，可能发生死锁，可以看看如下代码：

private Object a=new Object();
private Object b=new Object();
public void callAB(){
	synchronized(a){
		synchronized(b){
			//do something
		}
	}
}
public void executeAB(){
	synchronized(b){
		synchronized(a){
			//do something
		}
	}
}

**volatile机制有所不同，它仅用于控制线程中对象的可见性，并不能保证在此对象上操作的原子性。**就像上面的i++操作，即使把i定义为volatile也是没用的。但对于定义为volatile的变量，线程不会将其从main memory 复制到work memory中，而是直接在main memory上操作，它的代价虽然低，但是不能保证原子性。

可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。 用volatile修饰的变量，就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序，即直接修改内存。所以对其他线程是可见的。
volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。

线程交互机制

线程交互最典型的就是连接池。连接池中通常会有get和return两种方法。return的时候会讲连接返回到缓存列表中，并将连接数+1。而get方法在判断可使用连接数为0后，就进入一个等待状态，当有连接返回到连接池时，应该通知get方法不需要等待了。JVM通过wait/notify/notifyAll来支持这种等待和唤醒的需求。

典型的代码如下：

public Connection get(){
	synchronized(this){
		if(free>0){
			free--;
			return cacheConnections.poll();
		}
		else{
			this.wait();
		}
	}
}
public void close(Connection conn){
	synchronized(this){
		free++;
		cacheConnection.offer(conn);
		this.notifyAll();
	}
}

在Sun JDK中，object.wait()还有可能被虚假唤醒（也就是说原本只能唤醒一个人，现在唤醒了两个人，都先后拿到了锁，然而池中只有一根冰棒，），因此需要在此确认状态是否变更了，这种做法称为double check。（具体可以看看懒汉单例模式或者生产者消费者模式）
单例模式：

public static Singleton2 getInstance(){
        if(instance == null) {
            synchronized (Singleton2.class){
                instance = new Singleton2();
            }
        }
        return instance;
    }

变更为：

public static Singleton2 getInstance(){
        if(instance == null) {
            synchronized (Singleton2.class){
                if (instance == null){
                    instance = new Singleton2();
                }
            }
        }
        return instance;
    }

这里解释一下为什么synchronized为什么不写成这样：

public static Singleton2 getInstance(){
            synchronized (Singleton2.class){
                if (instance == null){
                    instance = new Singleton2();
                }
            }
        return instance;
    }

其实这是一个效率问题：是由于如果加在synchronized下面的话，这其实与方法加锁没什么区别。每次运行进来，线程都会阻塞。而double check保证了在创建了新实例的时候，不会阻塞。

SpringMVC怎么保障线程安全的？

对此，我们先来看三个栗子：

@Controller
public void MainController{
	private int index=0;
	private static int STATICINDEX=0;
	
	@RequestMapping(xxx)
	public void getIndex(){
		....
		System.out.println("index:"+
			(index++)+",static index"+(STATICINDEX++));
		....
	}
}
结果：
index:0,static index:0
index:1,static index:1
index:2,static index:2

我们在类加上@Scope(value="prototype")后，其输出结果为：

结果：
index:0,static index:0
index:0,static index:1
index:0,static index:2

如果将@Scope(value="prototype")改为@Scope(value="singleton")，那么，输出结果为：

结果：
index:0,static index:0
index:1,static index:1
index:2,static index:2

做一个总结：springMVC默认为单例模式（包括controller/service/dao）。由上面三个例子可以知道：

• 单例模式的意思就是只有一个实例。单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。当多用户同时请求一个服务时，容器会给每一个请求分配一个线程，这是多个线程会并发执行该请求多对应的业务逻辑（成员方法），此时就要注意了，如果该处理逻辑中有对该单列状态的修改（体现为该单列的成员属性），则必须考虑线程同步问题。
• 尽量不要在controller里面去定义属性，如果在特殊情况需要定义属性的时候，那么就在类上面加上注解@Scope(“prototype”)改为多例的模式。

与SpringMVC不同的是，struts是基于类的属性进行发的，定义属性可以整个类通用，所以默认是多例，不然多线程访问肯定是共用类里面的属性值的，肯定是不安全的。所以对此，又产生如下的问题：

• SpringMVC是单例的，高并发情况下，如何保证性能的？

首先在大家的思考中，肯定有影响的，你想想，单例顾名思义：一个个排队过… 高访问量的时候，你能想象服务器的压力了… 而且用户体验也不怎么好，等待太久~

实质上这种理解是错误的，Java里有个API叫做ThreadLocal，spring单例模式下用它来切换不同线程之间的参数。用ThreadLocal是为了保证线程安全，实际上ThreadLoacal的key就是当前线程的Thread实例。单例模式下，spring把每个线程可能存在线程安全问题的参数值放进了ThreadLocal。这样虽然是一个实例在操作，但是不同线程下的数据互相之间都是隔离的，因为运行时创建和销毁的bean大大减少了，所以大多数场景下这种方式对内存资源的消耗较少，而且并发越高优势越明显。

• ThreadLocal和线程同步机制相比有什么优势呢？

ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。

而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

• 哪些因素造成了线程不安全？

如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。 或者说:一个类或者程序所提供的接口对于线程来说是原子操作或者多个线程之间的切换不会导致该接口的执行结果存在二义性,也就是说我们不用考虑同步的问题。线程安全问题都是由全局变量及静态变量引起的。
若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则就可能影响线程安全。