Java锁机制

PART ONE

--对象锁，一个人物可以多次获得对象的锁．JVM负责跟踪对象被枷锁的次数．

--类锁，synchronized static方法可以在类的范围内防止对static数据的并发访问．

--Brian同步规则：
    --如果正在写一个变量，她可能接下来被另一个线程读取
    --或者正在读取一个上一次已经被另一个线程写过的变量
    --读写线程都必须使用相同的监视器锁同步
    --每个访问临界共享资源的方法都必须被同步
    
--Lock优点
    --可以使用finally子句将系统维护在正确的状态；而内置的synchronized关键字，如果某些事物失败了，会抛出一个异常，但是没机会做去任何清理工作
    --控制粒度更精细．用synchronized关键字不能尝试着获取锁且最终获取锁会失败，或者尝试着获取锁一段时间，然后放弃它，要实现这些，要用concurrent类库
    
--原子性
    --字撕裂(long, double 被当作２个32位)
    
--可视性
    --一个任务做出的修改，即使在不中断的意义上讲是原子性的，对其他任务也可能是不可视的(例如，修改只是暂时性地存储在本地处理器的缓存中)，因此不同的任务对应用的状态有不同的视图．
    --同步机制强制在处理器系统中，一个任务做出的修改在应用中是可视的．如果没有同步机制，那么修改时可视将无法确定．
    --volatile，可确保应用中的可视性，即便使用了本地缓存，volatile域被会不立即被写入主存中，而读取操作就发生在主存中．
        --使用volatile而不是synchronized的唯一安全的情况是类中只有一个可变的域．

 

PART TWO

为何sleep block是可中断的，而IO block和Synchronized block是不可中断的？
--从代码中就可以看到，sleep是需要捕捉中断异常的．

关闭任务在其上发生阻塞的底层资源．

只要任务以不可中断的方式被阻塞，那么都有潜在的会锁住程序的可能．

在ReentrantLock上阻塞的任务具备可以被中断的能力，这与在synchronized方法或临界区上阻塞的任务完全不同．

与IO调用不同，NIO interrupt()可以打断被互斥所阻塞的调用．

当任务协作时，关键问题是这些任务之间的握手．为了实现这种握手，我们使用了相同的基础特性：互斥．

握手可以通过Object的方法wait()和notify()来安全地实现，或者并发类库具有await()和signal()方法的Condition对象．

--wait()使你可以等待某个条件的变化，通常这种条件由另一个任务来改变．为什么有wait呢，这是因为要解决忙等待的问题，这是一种不良的CPU周期使用方式．因此wait()会在等待外部世界产生变化的时候将任务挂起，并且只有在notify()/notifyAll()发生时，这个任务才会被唤醒并去检查所发生的变化．

因此，wait()提供了一种在任务之间对活动同步的方式．

--与sleep不同，wait()
    --在wait()期间对象锁是释放的．
    --可以通过notify()/notifyAll()，或者令时间到期，从wait()中恢复执行．

--只能在同步控制方法或同步控制块里调用wait/notify/notifyAll，因为不用操作锁，所以sleep可以在非同步控制方法里调用．

--每个对lock的调用都必须紧跟一个try-finally子句，用来保证在所有情况下都可以释放锁；在使用内建版本时，任务在可以调用await/signal/signalAll之前，必须有用这个锁．

--wait/notify以一种非常低级的方式解决了任务互操作问题，即每次交互时都握手．在许多情况下，可以使用更高的抽象级别，使用同步队列来解决任务协作问题．

--任务间使用管道进行输入/输出
--PipledReader与普通I/O之间最重要的差异－－PipedReader是可中断的，而System.in.read()是不可中断的．

--死锁条件
    --互斥．任务使用的资源中至少有一个是不能共享的．
    --至少有一个任务它必须持有一个资源且正在等待获取一个当前被别的任务持有的资源．
    --资源不能被任务抢占，任务必须把资源释放当作普通事件．
    --必须有循环等待．一个任务等待其他任务所持有的资源，后者又在等待另一个任务所持有的资源．