线程安全篇B
为了保持状态的一致性，需要在一个原子性操作中更新相关的状态变量，加锁，可以将一些混合操作变为原子性操作，从而保证线程安全。
锁
- 内部锁
Java提供了一个加强原子性的内在锁机理-同步块，其包含两部分，一部分是一个可以作为锁的对象的引用，另一部分是由这个锁保护的阻塞代码。同步方法是同步块的一个快捷体现，其作用于所有的方法体。
每一个Java对象都可以作为一个潜在的同步锁，这种内部构建的锁叫做内部锁或是管程锁。当线程进入同步块前会自动获得锁，并在执行退出(正常或异常的情况)后，自动释放锁。
内在锁是一种互斥锁，即至多有一个线程可以拥有锁。当线程A想要获得线程B获得的锁，它必须等待或者阻塞，直到B线程释放锁，若不释放，A会一直等待。
- 重入性
重入性指的是锁的获得基于每个线程，而不是基于每次调用；一个线程可以成功请求获得它已经持有的锁；
该特性的实现是因为锁的请求获得次数（lockcount）和持有它的线程的关联来实现的。当一个线程获得或者再次获得锁时，在虚拟机里将会lockcount+1，当一个同步块退出时，虚拟机会让lockcount-1。当lockcount=0时，该线程释放锁。
重入性简化了面向对象的并发操作，否则的话，像如下代码中，将会发生死锁。
public class Widget {
public synchronized void doSomething() {
...
}
}
public class LoggingWidget extends Widget {
public synchronized void doSomething() {
System.out.println(toString() + ": calling doSomething");
super.doSomething();
}
}
用锁保护状态
由于锁可以将对代码的访问变得序列化，因此可以使用锁来构建一些策略来保障共享状态的排他性。
一个可以被多个线程访问的可变状态，所有的访问都需要持有共同的锁，此时，我们称这个状态被这个锁保护。
对象的内部锁和它的状态没有内在的关联，一个对象的成员不会自动被其内部锁保护。获得一个对象的内部锁，仅仅会阻止其它线程获得这个锁，但并不妨碍其它线程访问这个对象。
每次共享时，一个可变状态需要指定一个具体的锁，并使其使用者知道是哪个锁。
对于每一个拥有多于一个变量的不变量来说，它的所有变量应该使用同一个锁来保护。
一个通用的锁策略是，将所有可变状态用一个对象封装起来，然后所有访问这些可变状态的代码都用这个对象的内部锁保护起来，用来防止并发访问。这种方式很常用，也很简单，但是这样会导致活性和性能问题。
活性和性能
不合适的同步，特别是同步耗时操作，会使得并发能力下降，甚至失去并发能力。
用两段代码解释更直观。
- 粗糙同步,省略了一些次要代码。Servlet框架的设计本意是同时处理多个请求，但是同步后的service方法一旦有耗时操作，那么由于同步的原因，其它的请求只能等上一个请求完成之后才能进行，降低了处理性能。
public class SynchronizedFactorizer extends GenericServlet implements Servlet {
@GuardedBy("this") private BigInteger lastNumber;
@GuardedBy("this") private BigInteger[] lastFactors;
public synchronized void service(ServletRequest req,
ServletResponse resp) {
BigInteger i = extractFromRequest(req);
if (i.equals(lastNumber))
encodeIntoResponse(resp, lastFactors);
else {
BigInteger[] factors = factor(i);
lastNumber = i;
lastFactors = factors;
encodeIntoResponse(resp, factors);
}
}
void encodeIntoResponse(ServletResponse resp, BigInteger[] factors) {
}
BigInteger extractFromRequest(ServletRequest req) {
return new BigInteger("7");
}
BigInteger[] factor(BigInteger i) {
// Doesn't really factor
return new BigInteger[] { i };
}
}
- 精细同步，只需进行精致的分割，改变同步的位置，便能尽可能的消除加锁对性能带来的影响。见代码：
public class CachedFactorizer extends GenericServlet implements Servlet {
@GuardedBy("this") private BigInteger lastNumber;
@GuardedBy("this") private BigInteger[] lastFactors;
@GuardedBy("this") private long hits;
@GuardedBy("this") private long cacheHits;
public synchronized long getHits() {
return hits;
}
public synchronized double getCacheHitRatio() {
return (double) cacheHits / (double) hits;
}
public void service(ServletRequest req, ServletResponse resp) {
BigInteger i = extractFromRequest(req);
BigInteger[] factors = null;
synchronized (this) {
++hits;
if (i.equals(lastNumber)) {
++cacheHits;
factors = lastFactors.clone();
}
}
if (factors == null) {
factors = factor(i);
synchronized (this) {
lastNumber = i;
lastFactors = factors.clone();
}
}
encodeIntoResponse(resp, factors);
}
void encodeIntoResponse(ServletResponse resp, BigInteger[] factors) {
}
BigInteger extractFromRequest(ServletRequest req) {
return new BigInteger("7");
}
BigInteger[] factor(BigInteger i) {
// Doesn't really factor
return new BigInteger[]{i};
}
}
如何确定同步块的大小需要考虑安全性，易用性和性能。有时候，易用性和性能是一对相对矛盾的设计指标。无论何时在使用锁时，应该考虑到被同步的代码能做什么，以及这些代码耗时大概多少。进行大量的计算或是存在潜在的阻塞操作，都有可能加长持有锁的时间，进一步影响到程序的活性和性能。
涉及大量计算和耗时操作（如net或者io）的代码，应避免持有锁。
//待下篇
网友评论