多线程（三：锁性能问题，管程MESA模型）

锁的性能问题：

     锁会带来性能问题，最好的方案是使用无锁的算法和数据结构。例如本地存储（Thread Local Storage, TLS），写入时复制（Copy-on-write），乐观锁等。JAVA并发包里面的原子类是一种无锁的数据结构，Disruptor 则是一个无锁的内存队列。

    减少锁持有的时间。互斥锁本质上就是将并行的锁串行化。所以要增加并行度，减少锁持有的时间。例如使用细粒度的锁，JAVA并发包里的ConcurrentHashMap，使用分段锁技术。还可以使用读写锁，读的时候没有锁写的时候才会互斥。

 

性能方面指标： 吞吐量，退出，并发量。

1 吞吐量： 单位时间内能够处理的请求数量，吞吐量越高，性能越好。

2 延迟： 发出请求到收到响应的时间。延迟越小，性能越好。

3 并发量： 同时请求的并发数。

 

管程

     管程：管理共享变量以及对共享变量的操作过程，让他们支持并发。 翻译为JAVA领域的语言就是，管理类的成员变量和成员方法，让这个类时线程安全的。

synchronized 及 wait()、notify()、notifyAll() 这三个方法都是管程的组成部分。而管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。 

  

mesa模型

   JAVA管程的实现参考的是MESA模型。并发领域的发展过程两大核心问题：互斥（同一时刻只允许一个线程访问临界资源），同步（线程之间如何通信，协作）。

管程将共享变量以及对共享变相的操作统一封装起来。管程将共享变量queue这个队列，和相关的操作入栈出栈都封装起来。线程们想访问共享变量queue，只能通过调用管程提供的出栈入栈方法实现，期间保证互斥性，只允许一个线程进入管程。

    在管程模型里，共享变量和对共享变量的操作是被封装起来的，图中最外层的框就代表封装的意思。框的上面只有一个入口，并且在入口旁边还有一个入口等待队列。当多个线程同时试图进入管程内部时，只允许一个线程进入，其他线程则在入口等待队列中等待。管程里还引入了条件变量的概念，而且每个条件变量都对应有一个等待队列，如下图，条件变量 A 和条件变量 B 分别都有自己的等待队列。

 

管程内部，假设有个线程 T1 执行出队操作，不过需要注意的是执行出队操作，有个前提条件，就是队列不能是空的，而队列不空这个前提条件就是管程里的条件变量。 如果线程 T1 进入管程后恰好发现队列是空的，那怎么办呢？等待啊，去哪里等呢？就去条件变量对应的等待队列里面等。此时线程 T1 就去“队列不空”这个条件变量的等待队列中等待。这个过程类似于大夫发现你要去验个血，于是给你开了个验血的单子，你呢就去验血的队伍里排队。线程 T1 进入条件变量的等待队列后，是允许其他线程进入管程的。这和你去验血的时候，医生可以给其他患者诊治，道理都是一样的。

再假设之后另外一个线程 T2 执行入队操作，入队操作执行成功之后，“队列不空”这个条件对于线程 T1 来说已经满足了，此时线程 T2 要通知 T1，告诉它需要的条件已经满足了。当线程 T1 得到通知后，会从等待队列里面出来，但是出来之后不是马上执行，而是重新进入到入口等待队列里面。这个过程类似你验血完，回来找大夫，需要重新分诊。

    好处：notify（或notifyAll）、signal（或signalAll）不用放到代码的最后，T2也没有多余的阻塞唤醒操作。

    坏处：T1执行的时候，可能曾经满足过条件，现在已经不能满足了，需要增加循环验证条件方式。