Java多线程同步设计中利用Metux
副标题#e#
Mutex是互斥体,遍及地应用在多线程编程中。本文以广为流程的Doug Lea的concurrent东西包的Mutex实现为例,举办一点探讨。在Doug Lea的concurrent东西包中,Mutex实现了Sync接口,该接口是concurrent东西包中所有锁(lock)、门(gate)和条件变量(condition)的民众接口,Sync的实现类主要有:Mutex、Semaphore及其子类、Latch、CountDown、ReentrantLock等。这也浮现了面向抽象编程的思想,使我们可以在不改变代码可能改变少量代码的环境下,选择利用Sync的差异实现。下面是Sync接口的界说:
public interface Sync
{
public void acquire() throws InterruptedException;
//获取许可
public boolean attempt(long msecs) throws InterruptedException;
//实验获取许可
public void release();
//释放许可
}
通过利用Sync可以替代Java synchronized要害字,并提供越发机动的同步节制。虽然,并不是说 concurrent东西包是和Java synchronized独立的技能,其实concurrent东西包也是在synchronized的基本上搭建的,从下面临Mutex源码的理会即可以看到这一点。synchronized要害字仅在要领内可能代码块内有效,而利用Sync却可以超过要领甚至通过在工具之间通报,超过工具举办同步。这是Sync及concurrent东西包比直接利用synchronized越发强大的处所。
留意Sync中的acquire()和attempt()城市抛出InterruptedException,所以利用Sync及其子类时,挪用这些要领必然要捕捉InterruptedException。而release()要领并不会抛出InterruptedException,这是因为在acquire()和attempt()要领中大概会挪用wait()期待其它线程释放锁。而release()在实现长举办了简化,直接释放锁,不管是否真的持有。所以,你可以对一个并没有acquire()的线程挪用release()这也不会有什么问题。而由于release()不会抛出InterruptedException,所以我们可以在catch或finally子句中挪用release()以担保得到的锁可以或许被正确释放。好比:
class X
{
Sync gate; // ...
public void m()
{
try
{
gate.acquire();
// block until condition holds
try
{
// ... method body
}
finally { gate.release(); }
}
catch (InterruptedException ex) { // ... evasive action }
}
}
Mutex是一个非重入的互斥锁。Mutex遍及地用在需要超过要领的before/after范例的同步情况中。下面是Doug Lea的concurrent东西包中的Mutex的实现。
public class Mutex implements Sync
{
/** The lock status **/
protected boolean inuse_ = false;
public void acquire() throws InterruptedException
{
if (Thread.interrupted()) throw new InterruptedException();//(1)
synchronized(this)
{
try
{
while (inuse_) wait();
inuse_ = true;
}
catch (InterruptedException ex)
{
//(2)
notify();
throw ex;
}
}
}
public synchronized void release()
{
inuse_ = false;
notify();
}
public boolean attempt(long msecs) throws InterruptedException
{
if (Thread.interrupted()) throw new InterruptedException();
synchronized(this)
{
if (!inuse_)
{
inuse_ = true;
return true;
}
else if (msecs <= 0)
return false;
else
{
long waitTime = msecs;
long start = System.currentTimeMillis();
try
{
for (;;)
{
wait(waitTime);
if (!inuse_)
{
inuse_ = true;
return true;
}
else
{
waitTime = msecs - (System.currentTimeMillis() - start);
if (waitTime <= 0) // (3)
return false;
}
}
}
catch (InterruptedException ex)
{
notify();
throw ex;
}
}
}
}
}
#p#副标题#e#
为什么要在acquire()和attempt(0要领的开始都要查抄当前线程的间断符号呢?这是为了在当前线程已经被打断时,可以当即返回,而不会仍然在锁符号上期待。挪用一个线程的interrupt()要领按照当前线程所处的状态,大概发生两种差异的功效:当线程在运行进程中被打断,则配置当前线程的间断符号为true;假如当前线程阻塞于wait()、sleep()、join(),则当前线程的间断符号被清空,同时抛出InterruptedException。所以在上面代码的位置(2)也捕捉了InterruptedException,然后再次抛出InterruptedException。
release()要领简朴地重置inuse_符号,并通知其它线程。
#p#分页标题#e#
attempt()要领是操作Java的Object.wait(long)举办计时的,由于Object.wait(long)不是一个准确的时钟,所以attempt(long)要领也是一个大致的计时。留意代码中位置(3),在超时时返回。
Mutex是Sync的一个根基实现,除了实现了Sync接口中的要领外,并没有添加新的要领。所以,Mutex的利用和Sync的完全一样。在concurrent包的API中Doug给出了一个风雅锁定的List的实现示例,我们这儿也给出,作为对Mutex和Sync利用的一个例子:
class Node
{
Object item; Node next;
Mutex lock = new Mutex();
// 每一个节点都持有一个锁
Node(Object x, Node n)
{
item = x;
next = n;
}
}
class List
{
protected Node head;
// 指向列表的头
// 利用Java的synchronized掩护head域
// (我们虽然可以利用Mutex,可是这儿好像没有这样做的须要
protected synchronized Node getHead()
{ return head; }
boolean search(Object x) throws InterruptedException
{
Node p = getHead();
if (p == null) return false;
// (这儿可以越发紧凑,可是为了演示的清楚,各类环境都别离举办处理惩罚)
p.lock.acquire();
// Prime loop by acquiring first lock.
// (If the acquire fails due to
// interrupt, the method will throw
// InterruptedException now,
// so there is no need for any
// further cleanup.)
for (;;)
{
if (x.equals(p.item))
{
p.lock.release();
// 释放当前节点的锁
return true;
}
else
{
Node nextp = p.next;
if (nextp == null)
{
p.lock.release();
// 释放最后持有的锁
return false;
}
else
{
try
{
nextp.lock.acquire();
// 在释放当前锁之前获取下一个节点的锁
}
catch (InterruptedException ex)
{
p.lock.release();
// 假如获取失败,也释放当前的锁 throw ex;
}
p.lock.release();
// 释放上个节点的锁,此刻已经持有新的锁了
p = nextp;
}
}
}
}
synchronized void add(Object x)
{
// 利用synchronized掩护head域
head = new Node(x, head);
}
// ... other similar traversal and update methods ...
}