lock学习笔记01

关注

原创最新推荐文章于 2026-06-20 15:39:46 发布 208 阅读 AI 写同款· GEO 优化 ›

深入解析Java中的synchronized关键字接下来是偏向锁，我们还是用同样的代码即可，需要注意的是偏向锁必须在jvm启动后的一段时间才会运行，所以如果我们想打印偏向锁必须让线程休眠那么几秒，这里笔者就偷懒了一下，通过设置jvm参数。打印结果如下，我们只需关注第一行的object header，可以看到第一列的00000001，我们看到后3位为001，偏向锁标记为0，锁标记为01，001这就是我们说的无锁状态。上文讲解锁升级的之后，我们一直在说对象头的概念，所以为了能够直观的看到锁对象中对象头锁标记和锁状态的变化，我们这里引入一个jol工具。阅读详情

一：为什么要学习lock，synchronized和lock的区别

此部分转载，原文链接已失效

请注意， Lock实例只是普通对象，它们本身可以用作synchronized语句中的目标。获取Lock实例的监视器锁与调用该实例的任何lock()方法没有特定关系。建议为避免混淆，不要以这种方式使用Lock实例。

1、synchronized和lock的用法区别

synchronized：在需要同步的对象中加入此控制，synchronized可以加在方法上，也可以加在特定代码块中，括号中表示需要锁的对象。

lock：需要显示指定起始位置和终止位置。一般使用ReentrantLock类做为锁，多个线程中必须要使用一个ReentrantLock类做为对象才能保证锁的生效。且在加锁和解锁处需要通过lock()和unlock()显示指出。所以一般会在finally块中写unlock()以防死锁。

用法区别比较简单，这里不赘述了，如果不懂的可以看看Java基本语法。

2、synchronized和lock性能区别

synchronized是托管给JVM执行的，而lock是java写的控制锁的代码。在Java1.5中，synchronize是性能低效的。因为这是一个重量级操作，需要调用操作接口，导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象，性能更高一些。但是到了Java1.6，发生了变化。synchronize在语义上很清晰，可以进行很多优化，有适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地。

synchronized是托管给JVM执行的，所以在通知线程的时候是由虚拟机随机选择的（synchronized相当于整个lock对象只有一个单一的Condition对象，所有的线程等待、通知操作都由它完成，notifyall需要通知所有waitting线程），但是lock结合condition可以实现选择性通知（可以注册多个Condition，我们可以实现让每个Condition控制指定的一部分线程，这样一来，我们想选择性唤醒该部分线程，只需要调用控制那部分线程的Condition执行唤醒操作signalAll即可，其他线程仍保持waitting状态，这里涉及到condition的用法参考另一笔记，提一下signal与notify的区别，）

说到这里，还是想提一下这2中机制的具体区别。据我所知，synchronized原始采用的是CPU悲观锁机制，即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。而在CPU转换线程阻塞时会引起线程上下文切换，当有很多线程竞争锁的时候，会引起CPU频繁的上下文切换导致效率很低。

而Lock用的是乐观锁方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。乐观锁实现的机制就是CAS操作（Compare and Swap）。我们可以进一步研究ReentrantLock的源代码，会发现其中比较重要的获得锁的一个方法是compareAndSetState。这里其实就是调用的CPU提供的特殊指令。

现代的CPU提供了指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而 compareAndSet() 就用这些代替了锁定。这个算法称作非阻塞算法，意思是一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。

我也只是了解到这一步，具体到CPU的算法如果感兴趣的读者还可以在查阅下，如果有更好的解释也可以给我留言，我也学习下。

3、synchronized和lock用途区别

synchronized原语和ReentrantLock在一般情况下没有什么区别，但是在非常复杂的同步应用中，请考虑使用ReentrantLock，特别是遇到下面2种需求的时候。

3.1.某个线程在等待一个锁的控制权的这段时间需要中断
3.2.需要分开处理一些wait-notify，ReentrantLock里面的Condition应用，能够控制notify哪个线程
3.3.具有公平锁功能，每个到来的线程都将排队等候

先说第一种情况，ReentrantLock的lock机制有2种，忽略中断锁和响应中断锁，这给我们带来了很大的灵活性。比如：如果A、B2个线程去竞争锁，A线程得到了锁，B线程等待，但是A线程这个时候实在有太多事情要处理，就是一直不返回，B线程可能就会等不及了，想中断自己，不再等待这个锁了，转而处理其他事情。这个时候ReentrantLock就提供了2种机制，第一，B线程中断自己（或者别的线程中断它），但是ReentrantLock不去响应，继续让B线程等待，你再怎么中断，我全当耳边风（synchronized原语就是如此）；第二，B线程中断自己（或者别的线程中断它），ReentrantLock处理了这个中断，并且不再等待这个锁的到来，完全放弃。

这里来做个试验，首先搞一个Buffer类，它有读操作和写操作，为了不读到脏数据，写和读都需要加锁，我们先用synchronized原语来加锁，如下：

 	public class Buffer {   
 	 
 	    private Object lock;   
 	 
	    public Buffer() {
	        lock = this;
 	    }   
 	 
 	    public void write() {
 	        synchronized (lock) {
 	            long startTime = System.currentTimeMillis();
 	            System.out.println("开始往这个buff写入数据…");
 	            for (;;)// 模拟要处理很长时间
 	            {
 	                if (System.currentTimeMillis()
 	                        - startTime > Integer.MAX_VALUE)
 	                    break;
	            }
 	            System.out.println("终于写完了");
 	        }
 	    }   
 	 
 	    public void read() {
 	        synchronized (lock) {
 	            System.out.println("从这个buff读数据");
 	        }
 	    }
 	}

接着，我们来定义2个线程，一个线程去写，一个线程去读。

 	public class Writer extends Thread {   
 	 
 	    private Buffer buff;   
 	 
 	    public Writer(Buffer buff) {
 	        this.buff = buff;
 	    }   
 	 
 	    @Override
 	    public void run() {
 	        buff.write();
 	    }   
 	 
 	}   
	 
	public class Reader extends Thread {   
 	 
 	    private Buffer buff;   
 	 
 	    public Reader(Buffer buff) {
	        this.buff = buff;
	    }   
 	 
	    @Override
 	    public void run() {   
	 
	        buff.read();//这里估计会一直阻塞   
	 
 	        System.out.println("读结束");   
 	 
	    }   
	 
 	}

好了，写一个Main来试验下，我们有意先去“写”，然后让“读”等待，“写”的时间是无穷的，就看“读”能不能放弃了。

 	public class Test {
 	    public static void main(String[] args) {
 	        Buffer buff = new Buffer();   
 	 
 	        final Writer writer = new Writer(buff);
 	        final Reader reader = new Reader(buff);   
 	 
 	        writer.start();
 	        reader.start();   
 	 
 	        new Thread(new Runnable() {   
 	 
 	            @Override
 	            public void run() {
 	                long start = System.currentTimeMillis();
 	                for (;;) {
 	                    //等5秒钟去中断读
 	                    if (System.currentTimeMillis()
	                            - start > 5000) {
 	                        System.out.println("不等了，尝试中断");
 	                        reader.interrupt();
 	                        break;
 	                    }   
 	 
 	                }   
 	 
 	            }
 	        }).start();   
 	 
	    }
 	}

我们期待“读”这个线程能退出等待锁，可是事与愿违，一旦读这个线程发现自己得不到锁，就一直开始等待了，就算它等死，也得不到锁，因为写线程要21亿秒才能完成 T_T ，即使我们中断它，它都不来响应下，看来真的要等死了。这个时候，ReentrantLock给了一种机制让我们来响应中断，让“读”能伸能屈，勇敢放弃对这个锁的等待。我们来改写Buffer这个类，就叫BufferInterruptibly吧，可中断缓存。

import java.util.concurrent.locks.ReentrantLock;

public class BufferInterruptibly {

	private ReentrantLock lock = new ReentrantLock();

	public void write() {
		lock.lock();
		try {
			long startTime = System.currentTimeMillis();
			System.out.println("开始往这个buff写入数据…");
			for (; ; )// 模拟要处理很长时间
			{
				if (System.currentTimeMillis()
						- startTime > Integer.MAX_VALUE)
					break;
			}
			System.out.println("终于写完了");
		} finally {
			lock.unlock();
		}
	}

	public void read() throws InterruptedException {
		lock.lockInterruptibly();// 注意这里，可以响应中断
		try {
			System.out.println("从这个buff读数据");
		} finally {
			lock.unlock();
		}
	}

}

当然，要对reader和writer做响应的修改

class Reader extends Thread {

	private BufferInterruptibly buff;

	public Reader(BufferInterruptibly buff) {
		this.buff = buff;
	}

	@Override
	public void run() {

		try {
			buff.read();//可以收到中断的异常，从而有效退出
		} catch (InterruptedException e) {
			System.out.println("我不读了");
		}

		System.out.println("读结束");

	}

}

/**
 * Writer倒不用怎么改动
 */
class Writer extends Thread {

	private BufferInterruptibly buff;

	public Writer(BufferInterruptibly buff) {
		this.buff = buff;
	}

	@Override
	public void run() {
		buff.write();
	}

}

class Test {
	public static void main(String[] args) {
		BufferInterruptibly buff = new BufferInterruptibly();

		final Writer writer = new Writer(buff);
		final Reader reader = new Reader(buff);

		writer.start();
		reader.start();

		new Thread(new Runnable() {

			@Override
			public void run() {
				long start = System.currentTimeMillis();
				for (; ; ) {
					if (System.currentTimeMillis()
							- start > 5000) {
						System.out.println("不等了，尝试中断");
						reader.interrupt();
						break;
					}

				}

			}
		}).start();

	}
}

这次“读”线程接收到了lock.lockInterruptibly()中断，并且有效处理了这个“异常”。

至于第二种情况，ReentrantLock可以与Condition的配合使用，Condition为ReentrantLock锁的等待和释放提供控制逻辑。
例如，使用ReentrantLock加锁之后，可以通过它自身的Condition.await()方法释放该锁，线程在此等待Condition.signal()方法，然后继续执行下去。await方法需要放在while循环中，因此，在不同线程之间实现并发控制，还需要一个volatile的变量（synchronized关键字具有volatile的使变量在多线程间可视化功能，所以不需要），boolean是原子性的变量。因此，一般的并发控制的操作逻辑如下所示：

	volatile boolean isProcess = false;
	ReentrantLock lock  = new ReentrantLock();
 	Condtion processReady = lock.newCondtion();
	thread: run() {
 	    lock.lock();
	    isProcess = true;
	   try {
	    while(!isProcessReady) {  //isProcessReady 是另外一个线程的控制变量
	      processReady.await();//释放了lock，在此等待signal
 	     }catch (InterruptedException e) {
 	          Thread.currentThread().interrupt();
 	        } finally {
	          lock.unlock();
 	          isProcess = false;
	        }
 	      }
 	    }
 	}

这里只是代码使用的一段简化，下面我们看Hadoop的一段摘取的源码：

 	private class MapOutputBuffer<K extends Object, V extends Object>
 	      implements MapOutputCollector<K, V>, IndexedSortable {
 	...
 	    boolean spillInProgress;
 	    final ReentrantLock spillLock = new ReentrantLock();
 	    final Condition spillDone = spillLock.newCondition();
 	    final Condition spillReady = spillLock.newCondition();
 	    volatile boolean spillThreadRunning = false;
 	    final SpillThread spillThread = new SpillThread();
 	...
 	    public MapOutputBuffer(TaskUmbilicalProtocol umbilical, JobConf job,
 	                           TaskReporter reporter
 	                           ) throws IOException, ClassNotFoundException {
 	    ...
 	      spillInProgress = false;
 	      spillThread.setDaemon(true);
	      spillThread.setName("SpillThread");
 	      spillLock.lock();
 	      try {
	        spillThread.start();
 	        while (!spillThreadRunning) {
	          spillDone.await();
 	        }
	      } catch (InterruptedException e) {
	        throw new IOException("Spill thread failed to initialize", e);
 	      } finally {
 	        spillLock.unlock();
 	      }
 	    }
 	 
 	    protected class SpillThread extends Thread {
 	 
 	      @Override
 	      public void run() {
 	        spillLock.lock();
	        spillThreadRunning = true;
	        try {
 	          while (true) {
 	            spillDone.signal();
 	            while (!spillInProgress) {
	              spillReady.await();
 	            }
 	            try {
 	              spillLock.unlock();
	              sortAndSpill();
	            } catch (Throwable t) {
	              sortSpillException = t;
	            } finally {
	              spillLock.lock();
	              if (bufend < bufstart) {
 	                bufvoid = kvbuffer.length;
 	              }
 	              kvstart = kvend;
 	              bufstart = bufend;
 	              spillInProgress = false;
 	            }
	          }
	        } catch (InterruptedException e) {
	          Thread.currentThread().interrupt();
	        } finally {
	          spillLock.unlock();
 	          spillThreadRunning = false;
 	        }
 	      }
 	    }

代码中spillDone 就是 spillLock的一个newCondition()。调用spillDone.await()时可以释放spillLock锁，线程进入阻塞状态，而等待其他线程的 spillDone.signal()操作时，就会唤醒线程，重新持有spillLock锁。

这里可以看出，利用lock可以使我们多线程交互变得方便，而使用synchronized则无法做到这点。

最后呢，ReentrantLock这个类还提供了2种竞争锁的机制：公平锁和非公平锁。这2种机制的意思从字面上也能了解个大概：即对于多线程来说，公平锁会依赖线程进来的顺序，后进来的线程后获得锁。而非公平锁的意思就是后进来的锁也可以和前边等待锁的线程同时竞争锁资源。对于效率来讲，当然是非公平锁效率更高，因为公平锁还要判断是不是线程队列的第一个才会让线程获得锁。

收录于