- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章浅谈JAVA 线程状态中可能存在的一些误区由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
BLOCKED 和 WAITING 两种状态从结果上来看,都是线程暂停,不会占用 CPU 资源,不过还是有一些区别的 。
等待 Monitor 锁的阻塞线程的线程状态,处于阻塞状态的线程正在等待 Monitor 锁进入 synchronized Block 或者 Method ,或者在调用 Object.wait 后重新进入同步块/方法。简单的说,就是线程等待 synchronized 形式的锁时的状态 。
下面这段代码中, t1 在等待 t0 的锁释放(synchronized代码块执行完成),那么此时 t1 的状态就是 BLOCKED 。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
Object lock =
new
Object();
Thread t0 =
new
Thread(
new
Runnable() {
@Override
public
void
run() {
synchronized
(lock){
System.out.println(
"t0 acquire lock success"
);
try
{
Thread.sleep(
10000
);
}
catch
(InterruptedException e) {
e.printStackTrace();
}
}
}
});
t0.start();
Thread.sleep(
100
);
Thread t1 =
new
Thread(
new
Runnable() {
@Override
public
void
run() {
synchronized
(lock){
System.out.println(
"t1 acquire lock success"
);
}
}
});
t1.start();
Thread.sleep(
100
);
System.out.println(
"t0 state: "
+t0.getState());
System.out.println(
"t1 state: "
+t1.getState());
System.out.println(
"done."
);
//output
t0 acquire lock success
t0 state: TIMED_WAITING
t1 state: BLOCKED
done.
t1 acquire lock success
|
等待中的线程状态,下面几个方法的调用会导致线程进入 WAITING 状态:
WAITING 状态中的线程在等待其他线程执行某些操作,比如在某个对象上调用 Object.wait() 的线程正在等待另一个线程在该对象上调用 Object.notify() 或 Object.notifyAll()。为 Thread.join() 的线程正在等待指定的线程停止。 下面这段代码中,t0 在通过 synchronized 获取了 lock 对象的锁之后,进行了 wait 操作,导致 t0 进入 WAITING 状态:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
Object lock =
new
Object();
Thread t0 =
new
Thread(
new
Runnable() {
@Override
public
void
run() {
synchronized
(lock){
System.out.println(
"t0 acquire lock success"
);
try
{
lock.wait();
}
catch
(InterruptedException e) {
e.printStackTrace();
}
}
}
});
t0.start();
Thread.sleep(
100
);
System.out.println(
"t0 state: "
+t0.getState());
System.out.println(
"done."
);
//output
t0 acquire lock success
t0 state: WAITING
done.
|
JAVA 中除了 synchronized Block/Method 的锁,还提供了 JUC 下的锁实现, juc.lock 下的锁功能更强大。比如支持中断,支持重入/非重入,公平/非公平等;但是 juc 下的锁和 synchronized 的实现可是不太一样的 比如下面这段代码,同样是等待锁,可是和synchronized等待锁的状态还不一样:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
ReentrantLock reentrantLock =
new
ReentrantLock();
Thread t0 =
new
Thread(
new
Runnable() {
@Override
public
void
run() {
reentrantLock.lock();
System.out.println(
"t0 acquire lock success"
);
try
{
Thread.sleep(
10000
);
}
catch
(InterruptedException e) {
e.printStackTrace();
}
}
});
t0.start();
Thread.sleep(
100
);
Thread t1 =
new
Thread(
new
Runnable() {
@Override
public
void
run() {
reentrantLock.lock();
System.out.println(
"t1 acquire lock success"
);
}
});
t1.start();
Thread.sleep(
100
);
System.out.println(
"t0 state: "
+t0.getState());
System.out.println(
"t1 state: "
+t1.getState());
System.out.println(
"done."
);
//output
t0 acquire lock success
t0 state: TIMED_WAITING
t1 state: WAITING
done.
|
同样是加锁,在 JUC 的锁实现下线程状态不太一样,所以在观察线程状态时,不止是 BLOCKED 的状态才是等待锁, WAITING/TIMEWAITING 的状态仍然可能是等待锁的状态 不过 JUC 下的锁实现,让线程暂停/等待的核心方法还是 LockSupport.park , jstack 对于 PARKING 形式的 WAITING 会有标注,所以在线程 stack 时还是能一眼看出来的:
//这里显示了等待类型 "Thread-0" #11 prio=5 os_prio=31 tid=0x00007f9308110000 nid=0x5c03 waiting on condition [0x0000700007fc3000] java.lang.Thread.State: WAITING (parking)//这里虽然是WAITING,但还是标注了是parking类型的 at sun.misc.Unsafe.park(Native Method) 。
而 synchronized 形式的锁在 jstack 下的输出会有所区别:
//这里显示了等待类型为monitor "Thread-1" #12 prio=5 os_prio=31 tid=0x00007f833d919800 nid=0x5a03 waiting for monitor entry [0x00007000035af000] java.lang.Thread.State: BLOCKED (on object monitor)//这里是BLOCKED状态,同时显示了monitor的归属 。
所以在观察线程状态时,需要注意Object.wait()这种WAITING和juc下锁导致的WAITING的区别 。
下面是一段 jstack 输出的例子,该线程现在正在执行 socketRead0 方法(Native),并且是 RUNNABLE 状态 。
"RMI TCP Connection(2)-192.xxx.xx.xx" daemon prio=6 tid=0x000000000a3e8800 nid=0x158e50 runnable [0x000000000adbe000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) - locked (0x00000007ad784010) (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 。
但其实这里的 RUNNABLE 只是 JAVA 层面的线程状态,在操作系统或进程角度来看,该线程还是 WAITING 的状态; SocketInputStream 是一个 BIO 的实现,当没有收到数据(或者说没有准备好可读的数据)时会发生阻塞,可这个阻塞在JAVA线程状态里是 RUNNABLE 的状态,不过他并不会占用用户态的 CPU 时间片,内核在接受到数据后会结束这个阻塞 。
https://blog.fastthread.io/2018/09/02/threads-stuck-in-java-net-socketinputstream-socketread0/ 。
到此这篇关于浅谈JAVA 线程状态中可能存在的一些误区的文章就介绍到这了,更多相关JAVA 线程状态内容请搜索我以前的文章或继续浏览下面的相关文章希望大家以后多多支持我! 。
原文链接:https://juejin.cn/post/6951187747189194782 。
最后此篇关于浅谈JAVA 线程状态中可能存在的一些误区的文章就讲到这里了,如果你想了解更多关于浅谈JAVA 线程状态中可能存在的一些误区的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我最近在做一个基于 TensorFlow 的 Udacity 深度学习类(class)。 .我有一个简单的 MNIST大约 92% 准确的程序: from tensorflow.examples.tu
意识不到误区的存在最为离谱; 01 生活中,职场上,游戏里,都少不了正面对喷过:意识太差; 在个人的认知中意识即思维,意识太差即思维中存在的误区比较多;
我是一名优秀的程序员,十分优秀!