拋出synchronized问题：
对于一个方法上了同锁如果被一个线程占有了，而假如该线程长时间工作，那其它线程不就只能傻傻的等着，而且是无限的等这线程工作完成了才能执行自己的任务，这里来演示一下这种场景：
上面代码就是开启了两个线程，执行顺序有先后，分别执行这个同步方法，看下结果：
对于线程的中止其实是有系统API的，咱们可以试验一上试图打断t2线程不让他傻傻的一直等着了：
看结果：
因为同步代码块中是一个while的死循环，接收不到中断异常的，所以基于这个场景咱们需要自己来定义一个带有超时功能的锁，下面开始。
不包括超时的Lock:
其实在java5的并发包中专门的Lock，这里校仿一下系统的实现，先新建一个接口，将其锁的行为给定义一下：
然后新建一个具体类来实现该接口：
下面先来实现lock()方法，这里先定义两个成员变量：
首先判断是否锁被其它线程给占用了，如果占用了将当前线程加入阻塞集合中：
但！！！目前代码是有问题的，根据之前所学对于wait()是一定得要有一个monitor才行，否则肯定会报错，所以：
当这个循环条件退出了那证明就拿到了锁，所以接着处理正常的情况：
接下来实现unlock方法，比较容易理解直接贴出代码：
然后再将阻塞的查询方法给实现：
但是此次有一个细节问题：就是getBlockedThreads方法是直接将这个集合给返回给调用者了，此时调用者是可以修改Lock里面的blockedThreadCollection对象的，所以目前这样直接返回不太安全，应该包装一下不能让调用者来修改它，如下：
看一下官方的说明：
好，接下来使用一下咱们自己写的Lock,如下：
编译运行：
呃，抛异常了，在unlock()方法中的notifyAll()，它跟wait()方法一样也是需要一个monitor，所以修改代码如下：
再次运行：
这样咱们自己就定义了一个跟syncronized关键字类似的效果，只有一个线程执行完了其它线程才有机会去工作，不过目前的Lock还有一个问题，就是调用者可以随意的调用咱们封装的unlock()方法，而造成的影响嘛，下面做实验来说明一下：
看结果：
所以~~拉下来解决这个问题，其实解决也很简单，在Lock中加入一个变量用来记录lock()的线程，然后在unlock()时做一个判断，具体做法如下：
/** * 以boolean来实现锁 */ public class BooleanLock implements Lock { //如果为true代表已经被其它线程抢到锁了；否则代表锁是空闲的还木有被其它线程占有 private boolean initValue; //当前拿到锁的线程，以便用来控制释放锁状态问题 private Thread currentThread; //阻塞的线程集合 private Collection<Thread> blockedThreadCollection = new ArrayList<>(); @Override public synchronized void lock() throws InterruptedException { while (initValue) {//说明锁已经被其它线程占用了，此时让线程进入等待状态 blockedThreadCollection.add(Thread.currentThread()); this.wait(); } blockedThreadCollection.remove(Thread.currentThread()); this.initValue = true; currentThread = Thread.currentThread(); } @Override public void lock(long timeOutMills) throws InterruptedException, TimeOutException { } @Override public synchronized void unlock() { if (Thread.currentThread() == currentThread) { this.initValue = false; Optional.of(Thread.currentThread().getName() + " release the lock monitor.").ifPresent(System.out::println); this.notifyAll(); } } @Override public Collection<Thread> getBlockedThreads() { return Collections.unmodifiableCollection(blockedThreadCollection); } @Override public int getBlockedSize() { return blockedThreadCollection.size(); } }
编译运行：
就成功修复了这个BUG。
超时的Lock:
好，如文篇描述开头所抛出的synchronized所存在问题，这里通过咱们自己的写的锁来解决一下，当然此时就需要实现Lock中最后一个木有实现的方法了，如下：
那如何实现呢？其逻辑也比较简单，这里就不多解释了，直接贴代码：
/** * 以boolean来实现锁 */ public class BooleanLock implements Lock { //如果为true代表已经被其它线程抢到锁了；否则代表锁是空闲的还木有被其它线程占有 private boolean initValue; //当前拿到锁的线程，以便用来控制释放锁状态问题 private Thread currentThread; //阻塞的线程集合 private Collection<Thread> blockedThreadCollection = new ArrayList<>(); @Override public synchronized void lock() throws InterruptedException { while (initValue) {//说明锁已经被其它线程占用了，此时让线程进入等待状态 blockedThreadCollection.add(Thread.currentThread()); this.wait(); } blockedThreadCollection.remove(Thread.currentThread()); this.initValue = true; currentThread = Thread.currentThread(); } @Override public synchronized void lock(long timeOutMills) throws InterruptedException, TimeOutException { if (timeOutMills <= 0)//先做一个容错处理 lock(); long hasRemaining = timeOutMills; long endTime = System.currentTimeMillis() + timeOutMills; while (initValue) { if (hasRemaining <= 0) throw new TimeOutException("Time out"); blockedThreadCollection.add(Thread.currentThread()); this.wait(timeOutMills);//此时需要调用带参数的wait()方法啦 hasRemaining = endTime - System.currentTimeMillis(); } blockedThreadCollection.remove(Thread.currentThread()); this.initValue = true; currentThread = Thread.currentThread(); } @Override public synchronized void unlock() { if (Thread.currentThread() == currentThread) { this.initValue = false; Optional.of(Thread.currentThread().getName() + " release the lock monitor.").ifPresent(System.out::println); this.notifyAll(); } } @Override public Collection<Thread> getBlockedThreads() { return Collections.unmodifiableCollection(blockedThreadCollection); } @Override public int getBlockedSize() { return blockedThreadCollection.size(); } }
接着来改一下测试代码：
编译运行：
