锁的疑问和总结

获取不到 synchronized 内部锁的阻塞线程什么时候会释放?<核心>p634 14.3.3 节

　　当线程尝试获得锁的时候,如果锁被其他线程占用,那么这个线程就会进入阻塞状态(不管是内部锁,还是ReentrantLock).只有在其他线程释放锁的时候,而且线程调度器允许这个线程持有这个锁的时候,这个线程才会变成非阻塞状态.

　　同时当线程处于这种因获取锁而进入的阻塞状态,就是遇到了lock()方法而阻塞,是不可以被中断的.内部锁(synchronized)的也是lock() 方法.

　　而另外一种获取锁的方法,tryLock 则是可以被中断的.

　　所以synchronized 正在获取锁的线程不能被中断,而ReentrantLock 的可以(通过使用tryLock方法.)

获取到synchronized 的线程可sleep 否?能手动解锁否?能被中断吗?

　　synchronized 锁会自动获取一个内部锁,和ReentrantLock 的锁一样.而synchronized 的锁定的代码之间也是可以试用sleep 方法的,所以是可以sleep.

　　synchronized 不能手动解锁,没有lock.unlock 这个方法.

　　synchronized 和一般的锁一样,所以是可以被中断的.就是锁在锁内部你可以检测中断状态来决定如何处理中断.

线程阻塞或等待的总结:<核心>p648

1.线程会因为尝试去获得锁而阻塞.不可中断,由cpu决定是否非阻塞

2.因为条件对象的wait()/await() 方法而等待.这种等待状态需要先用条件解除等待,如signalAll 或notifyAll,解除后还是处于等待获取锁的阻塞状态,再等待其他线程释放锁,这些线程才可能变成非阻塞(转换为情况1了)

3.因为sleep,join() 方法而等待.可被中断.

线程中断信号的处理:

1.因情况2 和情况3进入等待或阻塞状态时,遇到中断会抛出中断异常.

2.因情况1进入阻塞时,遇到中断信号,会因阻塞而不能处理,要等到线程转为非阻塞时才会去处理.

3.线程正常允许时,遇到中断信号,则看代码有没有侦测到信号,还有怎样处理.参考:<核心>p631

不同对象变量中的synchronized("lock") 会是同一个吗?会不会互斥? synchronized 中的关键字是字符串,字符串相同则是同一个常量(没有new),这是不是意味着是同一个锁?

　　因为字符串常量指向同一个对象,所以是同一个锁,会互斥.new 出来的字符串则不是同一个对象,不是同一个锁.

ReentrantReadWriteLock 的总结:

(a).重入方面其内部的WriteLock可以获取ReadLock，但是反过来ReadLock想要获得WriteLock则永远都不要想。

(b).WriteLock可以降级为ReadLock，顺序是：先获得WriteLock再获得ReadLock，然后释放WriteLock，这时候线程将保持Readlock的持 有。反过来ReadLock想要升级为WriteLock则不可能，为什么？参看(a)

(c).ReadLock可以被多个线程持有并且在作用时排斥任何的WriteLock，多个被ReadLock 锁定的代码模块之间不会互斥,而WriteLock则是完全的互斥。这一特性最为重要，因为对于高 读取频率而相对较低写入的数据结构，使用此类锁同步机制则可以提高并发量。

(d).不管是ReadLock还是WriteLock都支持Interrupt，语义与ReentrantLock一致。

(e).WriteLock支持Condition并且与ReentrantLock语义一致，而ReadLock则不能使用Condition，否则抛出 UnsupportedOperationException异常。

(f).在ReadLock 中也是可以执行实际上的写操作,如写入文件内容之类的.命名为ReadLock 的意思是指锁的共享,和WriteLock 的独享不同.

关于锁的疑问:????????

1. 上锁的方法被继承之后也是被上锁的吗？需要测试两种锁。