关于synchronized与volatile的一点认识

贪婪是一种原罪，不要再追求性能的路上离正确越来越远。

• 内存模型
  • java内存模型

  • pageId=27903261#%E5%85%B3%E4%BA%8Esynchronized%E4%B8%8Evolatile%E7%9A%84%E4%B8%80%E7%82%B9%E8%AE%A4%E8%AF%86-%E9%87%8D%E6%8E%92%E5%BA%8F" style="color:rgb(0,109,175); text-decoration:none">重排序

• 锁synchronized
  • 什么是锁

  • pageId=27903261#%E5%85%B3%E4%BA%8Esynchronized%E4%B8%8Evolatile%E7%9A%84%E4%B8%80%E7%82%B9%E8%AE%A4%E8%AF%86-%E7%8B%AC%E5%8D%A0%E9%94%81" style="color:rgb(0,109,175); text-decoration:none">独占锁

  • pageId=27903261#%E5%85%B3%E4%BA%8Esynchronized%E4%B8%8Evolatile%E7%9A%84%E4%B8%80%E7%82%B9%E8%AE%A4%E8%AF%86-%E5%88%86%E6%8B%86%E9%94%81" style="color:rgb(0,109,175); text-decoration:none">分拆锁

  • pageId=27903261#%E5%85%B3%E4%BA%8Esynchronized%E4%B8%8Evolatile%E7%9A%84%E4%B8%80%E7%82%B9%E8%AE%A4%E8%AF%86-%E5%88%86%E7%A6%BB%E9%94%81" style="color:rgb(0,109,175); text-decoration:none">分离锁

  • 分布式锁
• volatile

内存模型

java内存模型

提到同步、锁。就必须提到java的内存模型，为了提高程序的运行效率。java也吸收了传统应用程序的多级缓存体系。



在共享内存的多处理器体系架构中，每一个处理器都拥有自己的缓存，而且定期地与主内存进行协调。在不同的处理器架构中提供了不同级别的缓存一致性（Cache Coherence）,当中一部分仅仅提供最小的保证，即同意不同的处理器在随意时刻从同一个存储位置上看到不同的值。操作系统、编译器以及执行时（有时甚至包含应用程序）须要弥合这样的在硬件能力与线程安全之间的差异。

要想确保每一个处理器都能在随意时刻知道其它处理器正在进行的工作，将须要很大的开销。

在大多数时间里。这样的信息是不必要的。

因此处理器会适当放宽存储一致性保证，以换取性能的提升。在架构定义的内存模型中将告诉应用程序能够从内存系统中获得如何的保证。此外还定义了一些特殊的指令（称为内存栅栏），当须要共享数据时，这些指令就能实现额外的存储协调保证。为了使java开发者无须关心不同架构内存模型之间的差异，Java还提供了自己的内存模型。而且JVM通过在适当的位置上插入内存栅栏来屏蔽在JVM与底层之平台内存模型之间的差异。

经过上面的解说和上图，我们知道线程在执行时候有一块内存专用区域。Java程序会将变量同步到线程所在的内存。这时候会操作工作内存中的变量。而线程中的变量何时同步回到内存是不可预期的。可是java内存模型规定，通过关键词”synchronized“、”volatile“能够让java保证某些约束。

“volatile” - 保证读写的都是主内存变量。 “synchronized” - 保证在块開始时。都同步主内存值到工作内存，而快结束时。将工作内存同步会主内存。

重排序

public class PossibleReordering {
    static int x = 0,y=0;
    static int a=0,b=0;
    public static void main(String[] args) throws InterruptedException {
        Thread one = new Thread(new Runnable() {

            @Override
            public void run() {
                a = 1;
                x = b;
            }
        });

        Thread two = new Thread(new Runnable() {

            @Override
            public void run() {
                b = 2;
                y = a;
            }
        });
        one.start();two.start();
        one.join();two.join();
        System.out.println("x:" + x+",y:"+y);
    }
}

重排序。如上图。运行结果，一般人可能觉得是1，1；真正的运行结果可能每次都不一样。拜JMM重排序所赐。JMM使得不同线程的操作顺序是不同的。从而导致在缺乏同步的情况下，要判断操作的运行结果将变得更加复杂。各种使操作延迟或看似乱序运行的不同原因，都能够归为重排序。内存级的重排序会使程序的行为变得不可预測。

假设没有同步，要判断出程序的运行顺序是很困难的。而要确保在程序中正确的使用同步却是很easy的。

同步将限制编译器和硬件运行时对内存操作重排序的方式。

锁synchronized

锁实现了对临界资源的相互排斥訪问，被synchronized修饰的代码仅仅有一条线程能够通过，是严格的排它锁、相互排斥锁。

没有获得相应锁对象监视器（monitor）的线程会进入等待队列。不论什么线程必须获得monitor的全部权才干够进入同步块，退出同步快或者遇到异常都要释放全部权，JVM规范通过两个内存屏障（memory barrier）命令来实现排它逻辑。内存屏障能够理解成顺序运行的一组CPU指令，全然无视指令重排序。

什么是锁

public class TestStatic {
	public syncronized static void write(boolean flag) {
		xxxxx
	}
	public synchronized static void read() {
		xxxxx
	}
}

线程1訪问TestStatic.write()方法时，线程2能訪问TestStatic.read()方法吗

线程1訪问new TestStatic().write()方法时，线程2能訪问new TestStatic().read()方法吗

线程1訪问TestStatic.write()方法时。线程2能訪问new TestStatic().read()方法吗

public class Test {
	public syncronized void write(boolean flag) {
			xxxxx
	 }
	public synchronized void read() {
		xxxxx
	}
}

Test test = new Test();线程1訪问test.write() 方法。线程2是否能訪问test.read()方法

Test a = new Test(); Test b = new Test();线程1訪问a.write()訪问，线程2是否能訪问b.read()方法

答案。java中每一个对象都能够作为一个锁，而对象就决定了锁的粒度大小。

对于实例同步方法，锁是当前对象。

对于静态方法。锁是TestSTatic.class对象

对于同步代码块。锁是Synchronized括号中面配置的对象

TestStatic类，1问，作用范围全体class对象。线程1拿到。线程2就不能拿到

2问，3问同上

Test类。1问，不能，锁都是实例对象test，线程1拿到锁之后，线程2无法訪问

2问，能够，线程1锁是实例a，线程2是实例b。

独占锁

假设你不敢确定该用什么锁，就用这个吧，在保证正确的前提下，兴许在提高开发效率。

public class ServerStatus {
	public final Set<String> users;
	public final Set<String> quers;
	public synchronized void addUser(String u ) {
		users.add(u);
	}
	public synchronized void addQuery(String q ) {
		quers.add(q);
	}
	public synchronized void removeUser(String u) {
		users.remove(u);
	}
	public synchronized void removeQuery(String q) {
		quers.remove(q);
	}
}

分拆锁

假设在整个应用程序仅仅有一个锁，而不是为每一个对象分配一个独立的锁，那么全部同步代码块的运行就会变成串行化运行。因为非常多线程都会竞争同一个全局锁，因此两个线程同一时候请求这个锁的概率将会剧增，从而导致更严重的竞争。

所以假设将这些锁请求分到很多其它的锁上，就能有效减少锁竞争程度。因为等待而被堵塞的线程将更少。从而可伸缩性将提高。

上文中users、quers是两个相互独立的变量，能够将此分解为两个独立的锁，每一个锁仅仅保护一个变量。减少每一个锁被请求的频率。

public class ServerStatus {
	public final Set<String> users;
	public final Set<String> quers;
	public void addUser(String u ) {
		synchronized(users) {
			users.add(u);
	  	}
	}
	public void addQuery(String q ) {
		synchronized(quers) {
			quers.add(q);
		}
	}
	public void removeUser(String u) {
		synchronized(users) {
			users.remove(u);
		}
	}
	public void removeQuery(String q) {
		synchronized(quers) {
			quers.remove(q);
		}
	}
}

分离锁

在某些情况下，能够将锁分解技术进一步扩展为对一组独立对象上的锁进行分解。这样的情况称为锁分段。

比如ConcurrencyHashMap是有一个包括16个锁的数组实现，每一个锁保护全部散列桶的1/16，当中第N个散列桶由第（N mod 16）个锁来保护。如果全部keyword都时间均与分布，那么相当于把锁的请求降低到原来的1/16，能够支持多达16个的并发写入。

锁分段的劣势在于：与採用单个锁来实现独占訪问相比，要获取多个锁来实现独占訪问将更加困难而且开销更高，比方计算size、重hash。

分布式锁

zookeeper。推断暂时节点是否存在，存在就说明已经有人争抢到锁；不存在就创建节点，表明拥有该锁。

记下，以后具体研究

https://github.com/qhwj2006/ZookeeperDistributedLock

https://github.com/s7/scale7-cages

volatile

volatile是比synchronized更轻量级的同步原语。volatile能够修饰实例变量、静态变量、以及数组变量（网上大牛说。维护的是引用，可是里面的对象。。

。

嘿嘿嘿）。

被volatile修饰的变量。JVM规范规定，一个线程在改动完，另外的线程能读取最新的值。

但只保证可见性，不保证原子性。所以volatile通经常使用来修饰boolean类型或者状态比較少的数据类型，并且不能用来更新依赖变量之前值的操作（例volatile++）。

volatile内部不过对变量的操作多了一条cpu指令（lock#指令），它会强制写数据到缓存，假设缓存数据同一时候也在主存。会强制写数据更新到主存，而且使全部持有该主存数据地址的缓存统统失效，触发其它持有缓存数据的线程从主存获取最新数据，从而实现同步。