java.util.concurrent(二) Lock

本文详细解析Java并发编程中的锁机制,重点对比Lock和synchronized的区别,包括Lock的优势、使用方式及性能表现,并通过生产者-消费者问题实例展示Lock的灵活运用。同时,介绍ReentrantLock的公平锁特性及其使用注意事项。

           在多线程编程中常常需要进行同步而锁定某个对象,通常采用synchronized来实现,部分情况下采用Java.util.concurrent.lock更加合适。ReentrantLock实现了Lock接口、是常用的实现类。

           

           Lock和synchronized有个明显的区别在于----lock必须在finally里面释放,如若不在finally中释放,则操作中抛出异常、锁又可能永远得不到释放,这点非常重要。

 

Lock lock = new ReentrantLock();
lock.lock();
try {
     // ...
} 
finally {
     lock.unlock();
}

 

 

          Lock的Condition使得Lock在使用的时候更加的灵活。Lock与synchronized的功能类似、进行同步,Condition则用于线程间通信、其提供的await()、signal()方法相对于wait()、notify()方法。condition与Lock绑定使用、一个Lock可通过Lock.newCondition()方法绑定多个condition,即相当于同一个锁有多个等待队列。相比较于synchronized灵活许多。下面以典型的生产者-消费者问题为例做个比较:

package producerConsumer;

import java.util.LinkedList;
import java.util.Queue;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

import producerConsumer.ProducerConsumer.Consumer;
import producerConsumer.ProducerConsumer.Producer;

public class ProducerConsumerLock {
	private static Queue<Object> myList = new LinkedList<Object>();
	private static final int MAX = 1;
	private static Lock lock = new ReentrantLock();
	private static Condition full = lock.newCondition();
	private static Condition empty = lock.newCondition();
	
	public static void main(String[] args) {
		for(int i = 0; i < 10; i++) {
			new Thread(new Producer(), "Producer" + i).start();
			new Thread(new Consumer(), "Consumer" + i).start();
		}
	}
	
	static class Producer extends Thread {
		public void run() {
			while(true) {
				lock.lock();
				try {
					while(myList.size() == MAX) {
						System.out.println("queue is full...");
						full.await();
					}
					Thread.currentThread().sleep(Math.round(100));
					Object o = new Object();
					myList.add(o);
					System.out.println("Producer-MQsize: " + myList.size() + "       name: " + Thread.currentThread().getName());
					empty.signal();
				} catch(Exception e) {
					e.printStackTrace();
				} finally {
					lock.unlock();
				}
			
			}
		}
	}
	
	static class Consumer extends Thread {
		public void run() {
			while(true) {
				lock.lock();
				try {
					while(myList.size() == 0) {
						System.out.println("queue is empty...");
						empty.await();
					}
					Thread.currentThread().sleep(Math.round(1000));
					Object o = myList.remove();
					System.out.println("Consumer-MQsize: " + myList.size() + "       name: " + Thread.currentThread().getName());
					full.signal();
				} catch(Exception e) {
					e.printStackTrace();
				} finally {
					lock.unlock();
				}
			}
		}
	}
}

 

           ReentrantLock通过其构造器的参数设置,可实现公平锁的功能,公平锁使线程按照请求锁的顺序依次获得锁。公平锁的性能开销非常大,因此ReentrantLock的默认设置时不公平的,除非公平对你的算法非常重要、必须严格按照线程排队的顺序进行服务,除此之外一般都不采用公平锁。

Lock lock = new ReentrantLock(false);//设置为true则为公平锁

 

          Lock的tryLock()也是一大特征、尝试获得锁,该方法立即返回结果、也可设置等待时间。

          Lock的性能方面表现也比synchronized优异,但是一般情况下不使用Lock。Lock与synchronized的具体区别以及选择如下 :http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html

<think>我们正在分析Java线程堆栈信息,特别是涉及`sun.misc.Unsafe.park`的线程阻塞问题。根据引用内容,`Unsafe.park`是一个本地方法,用于线程挂起(类似于`Object.wait()`),但它是特定于体系结构的,并且通常用于Java内部库(如线程池管理)以提供性能优化。 ### 线程状态分析 在Java线程堆栈中,当线程处于`WAITING`状态且堆栈跟踪显示在`sun.misc.Unsafe.park`时,通常表示线程正在等待某个条件(如锁、任务等)。这可能是正常行为(如线程池中的空闲线程),也可能表示潜在问题(如死锁或资源不足)。 ### 排查步骤 1. **识别线程状态**: - 使用`jstack <pid>`命令获取线程堆栈转储。 - 查找状态为`WAITING`或`TIMED_WAITING`且堆栈中包含`sun.misc.Unsafe.park`的线程。 2. **分析等待原因**: - 检查堆栈中`park`调用前的代码,确定是哪个同步器(如`LockSupport`、`ReentrantLock`、`CountDownLatch`等)调用了`park`。 - 例如,如果堆栈显示`java.util.concurrent.locks.LockSupport.park()`,则可能是锁或条件队列的等待。 3. **检查死锁**: - 使用`jstack`输出的死锁检测部分(如果有)或工具(如JConsole)检查死锁。 - 死锁通常涉及多个线程互相等待对方持有的锁。 4. **资源不足或超时**: - 如果线程在`TIMED_WAITING`状态,检查是否设置了合理的超时时间。 - 资源不足(如数据库连接池耗尽)也可能导致线程长时间等待。 5. **结合日志和上下文**: - 查看应用程序日志,了解在阻塞发生时的业务操作。 - 检查系统资源(CPU、内存、I/O)使用情况。 ### 示例堆栈分析 假设一个线程堆栈如下: ``` "pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x00007f487801a000 nid=0x2a1f waiting on condition [0x00007f486f7f7000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f5d1b2d0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at com.example.MyResource.process(MyResource.java:20) ... ``` 分析: - 线程`pool-1-thread-1`正在等待一个`ReentrantLock`(地址`0x00000000f5d1b2d0`)。 - 需要检查持有该锁的线程以及它为何长时间不释放。 ### 引用说明 - `Unsafe.park`是线程挂起的底层实现,常见于并发工具类(如线程池、锁)中[^1]。 - 在排查时,注意`park`调用前的同步器类型,这有助于定位问题来源。 ### 工具建议 - **jstack**:获取线程转储。 - **jvisualvm**或**JConsole**:图形化监控和线程分析。 - **Arthas**:在线诊断工具,支持线程堆栈查看和死锁检测。 ### 常见问题场景 1. **线程池配置不当**:核心线程数过小,任务队列过长导致等待。 2. **锁竞争激烈**:多个线程争用同一锁,导致某些线程长时间等待。 3. **外部资源依赖**:如数据库连接超时,网络请求阻塞等。 §§相关问题§§ 1. 如何区分`sun.misc.Unsafe.park`是正常等待还是死锁? 2. 使用哪些工具可以监控Java线程的阻塞情况? 3. 如何避免因线程阻塞导致的系统性能下降?</think>### Java线程堆栈分析与`sun.misc.Unsafe.park`阻塞问题排查 #### 1. **理解`Unsafe.park`的作用** - `Unsafe.park`是Java底层本地方法(Native Method),功能类似于`Thread.wait()`,用于挂起当前线程[^1]。 - 常见于并发工具类(如`LockSupport`、线程池、锁机制),通过直接调用体系结构特定代码优化性能[^1][^3]。 - **线程状态**:当堆栈显示`WAITING at sun.misc.Unsafe.park`时,表明线程因等待资源(如锁、任务)被挂起。 #### 2. **排查步骤** ##### (1) 获取线程堆栈信息 - 使用命令获取JVM线程转储: ```bash jstack <pid> > thread_dump.txt # 替换<pid>为Java进程ID ``` - 或通过JDK工具(JVisualVM、Arthas)在线分析。 ##### (2) 定位阻塞线程 在堆栈文件中搜索`Unsafe.park`,例如: ``` "main" #1 prio=5 os_prio=0 tid=0x00007f... nid=0x2a1f waiting on condition [0x...] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f5d1b2d0> # 等待的目标对象地址 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(...) ... ``` - **关键字段**: - `parking to wait for <地址>`:指出线程等待的资源(如锁对象)。 - 调用链:向上追溯调用者(如`LockSupport`、`ReentrantLock`)。 ##### (3) 分析阻塞原因 - **死锁检测**: - 检查是否有多个线程互相持有对方需要的锁(使用`jstack`输出的`Found one Java-level deadlock`部分)。 - 工具辅助:JConsole或VisualVM的“死锁检测”功能。 - **资源竞争**: - 若多个线程等待同一地址(如`<0x00000000f5d1b2d0>`),说明存在锁竞争。 - 结合代码确认同步块范围是否过大或锁粒度不合理。 - **任务队列空转**: - 线程池工作线程在`Unsafe.park`等待新任务,需检查任务提交是否阻塞或队列配置。 ##### (4) 结合日志和监控 - 检查应用日志中与阻塞相关的错误(如超时、资源不足)。 - 监控工具(Prometheus+Grafana)观察线程数、锁等待时间等指标。 #### 3. **常见场景与解决方案** | 场景 | 表现特征 | 解决方案 | |---------------------|---------------------------------|--------------------------------------------------------------------------| | **死锁** | 多个线程互相等待对方持有的锁 | 调整锁顺序;使用`tryLock`加超时;减少同步范围[^1] | | **线程池饥饿** | 工作线程全部`park`,但任务积压 | 增大核心线程数;优化任务拆分;检查任务提交逻辑[^3] | | **外部资源阻塞** | 等待数据库连接/网络响应时`park` | 设置合理超时;优化连接池(如HikariCP);熔断机制 | | **锁竞争激烈** | 大量线程`park`等待同一锁 | 减小锁粒度(如分段锁);改用无锁数据结构(`ConcurrentHashMap`) | | **框架冲突** | 如Spring Cloud Gateway因依赖冲突阻塞[^5] | 移除冲突依赖(如`spring-boot-starter-web`) | #### 4. **工具推荐** - **Arthas**:在线诊断工具,支持`thread -b`一键检测死锁。 - **JVisualVM**:图形化分析线程转储,直观展示锁持有关系。 - **Async-Profiler**:结合火焰图定位阻塞热点。 > **关键提示**:`Unsafe.park`本身是正常行为,需结合上下文判断是否异常。若线程长期`WAITING`且无唤醒机制,可能需检查代码逻辑(如遗漏`LockSupport.unpark()`)[^1][^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值