Java线程之活跃性危险

1. 活跃性危险

在安全性和活跃性之间存在某种制衡,我们使用加锁机制来确保线程安全,但是过度使用加锁,或使用不当,可能导致活跃性故障,最严重的情况下导致死锁。

1.1 死锁

在线程A持有锁L的同时,又想继续持有锁R;而线程B持有锁R,又想继续持有锁L。这两个线程将永远等待下去。

d69d06abaa63b89aac12dfb94a5d4962283.jpg

第一种解决办法是,让多组状态变量合并,从而变成只需要一把锁,这样多线程之间就不会发生死锁了。第二种办法是,如果合并不了,那就要控制锁的顺序,比如让所有线程都先拿锁L,再拿锁R。第三种办法是,尽量避免在一个加了锁的代码块里面再去获取别的锁。

1.2 饥饿

如果对线程的优先级设置不当,或者在持有锁的线程无限循环或无限等待某个资源,就会导致有的线程永远得不到锁,或很少机会得到锁,这就是饥饿。

应该尽量不要使用线程优先级,因为每个平台实现不一样,会产生不可预测的结果。

1.3 长时间不响应

如果某些计算密集型的线程一直在运行,就会导致其它线程很难得到CPU的时钟周期,导致其它线程响应慢。比如前台线程把任务交给后台线程后,后台线程执行计算密集型任务,会影响前台线程给客户响应的速度。

这种情况可以适当给计算密集型任务添加一些休眠时间,让其他线程有机会得到CPU的时钟周期。

1.4 活锁

有一种活锁是指线程不停重复执行相同操作,而且总是失败,屡败屡战。比如,当一个线程从一个任务队列里面取一个任务执行,失败后,把任务重新放回队列,稍后又执行,如此往复……这种活锁通常是由过度的错误恢复代码造成的,将不可修复的错误作为可修复的错误。

还有一种活锁出现在多个相互协作的线程场景下,假设有两个过于礼貌的人在路上面对面相遇,两个人先同时向右让,然后又同时向左让,如此反复……

要避免活锁问题,通常需要在重试机制中引入随机性,比如不要固定时间重试。

2. 监控线程

既然锁容易导致活跃性危险,就应该能够通过技术手段诊断出这些危险。下面介绍通过jstack来跟踪诊断问题。

2.1 死锁的示例代码

首先通过一段死锁代码开始:

public class DeadLock {
	public static void main(String[] args) {
		LeftThread lt = new LeftThread();
		RightThread rt = new RightThread();
		
		lt.setRightThread(rt);
		rt.setLeftThread(lt);
		

		new Thread(lt).start();
		new Thread(rt).start();

	}
}


class LeftThread implements Runnable {
	
	private RightThread rightThread;

	public void setRightThread(RightThread rightThread) {
		this.rightThread = rightThread;
	}

	@Override
	public void run() {
		this.letf();
	}
	
	public synchronized void letf() {
		System.out.println(Thread.currentThread().getId()+":I get left");
		try {
			Thread.sleep(1000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		rightThread.right();
	}
	
}

class RightThread implements Runnable {
	
	private LeftThread leftThread;

	public void setLeftThread(LeftThread leftThread) {
		this.leftThread = leftThread;
	}

	@Override
	public void run() {
		this.right();
		
	}
	
	public synchronized void right() {
		System.out.println(Thread.currentThread().getId()+":I get right");
		try {
			Thread.sleep(1000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		leftThread.letf();
	}
	
}

2.2 找出Java代码的进程PID

Windows系统可以通过资源管理器得到,Linux系统可以通过ps命令。

2.3 使用jstack命令查看进程内的所有线程状态

$ jstack pid

C:\Users\lenovo>jstack 4804
2018-06-10 10:15:19
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode):

"DestroyJavaVM" #12 prio=5 os_prio=0 tid=0x0000000003184800 nid=0x1354 waiting o
n condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #11 prio=5 os_prio=0 tid=0x000000001908d800 nid=0x107c waiting for mo
nitor entry [0x0000000019c6f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at LeftThread.letf(DeadLock.java:32)
        - waiting to lock <0x00000000d6f4a378> (a LeftThread)
        at RightThread.right(DeadLock.java:64)
        - locked <0x00000000d6f4bba0> (a RightThread)
        at RightThread.run(DeadLock.java:53)
        at java.lang.Thread.run(Thread.java:745)

"Thread-0" #10 prio=5 os_prio=0 tid=0x000000001908b000 nid=0x4b0 waiting for mon
itor entry [0x0000000019b6f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at RightThread.right(DeadLock.java:58)
        - waiting to lock <0x00000000d6f4bba0> (a RightThread)
        at LeftThread.letf(DeadLock.java:38)
        - locked <0x00000000d6f4a378> (a LeftThread)
        at LeftThread.run(DeadLock.java:28)
        at java.lang.Thread.run(Thread.java:745)

"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x0000000018ff0800 nid=0x15c run
nable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x0000000017c48000 nid=0x13c
0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x0000000017c45000 nid=0xaf4
 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x0000000017c3f800 nid=0x129
8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000018fb3800 nid=0x190 wa
iting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000000017c33000 nid=0xf60
runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000000327a800 nid=0x131c in Obje
ct.wait() [0x0000000018f6f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d6c06f58> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x00000000d6c06f58> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000017be9800 nid=0xc1c
 in Object.wait() [0x0000000018e6f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d6c06998> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
        - locked <0x00000000d6c06998> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=2 tid=0x0000000017be7000 nid=0xb74 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000319b000 nid=0xcb0 runna
ble

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000319c800 nid=0x12f4 runn
able

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000319e000 nid=0x480 runna
ble

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00000000031a0000 nid=0xda8 runna
ble

"VM Periodic Task Thread" os_prio=2 tid=0x0000000018ff1800 nid=0x874 waiting on
condition

JNI global references: 6


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x0000000003277858 (object 0x00000000d6f4a378, a LeftT
hread),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x000000000327a198 (object 0x00000000d6f4bba0, a Right
Thread),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at LeftThread.letf(DeadLock.java:32)
        - waiting to lock <0x00000000d6f4a378> (a LeftThread)
        at RightThread.right(DeadLock.java:64)
        - locked <0x00000000d6f4bba0> (a RightThread)
        at RightThread.run(DeadLock.java:53)
        at java.lang.Thread.run(Thread.java:745)
"Thread-0":
        at RightThread.right(DeadLock.java:58)
        - waiting to lock <0x00000000d6f4bba0> (a RightThread)
        at LeftThread.letf(DeadLock.java:38)
        - locked <0x00000000d6f4a378> (a LeftThread)
        at LeftThread.run(DeadLock.java:28)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

分析结果是一个线程运行的快照,把执行jstack命令的那一刻的线程状态全部记录下来,可以看到每个线程的状态,可以看到被阻塞的线程持有的锁,希望获取的锁……等信息。如果有死锁,还会直接给予提示。

转载于:https://my.oschina.net/leaforbook/blog/1827529

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值