锁的活跃性——死锁、活锁和饥饿

最新推荐文章于 2021-11-24 09:24:22 发布
最新推荐文章于 2021-11-24 09:24:22 发布
阅读量232 收藏
点赞数
分类专栏： Java并发编程 文章标签： 多线程 thread java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/salted___fish/article/details/107372497
版权

死锁

死锁现象

有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁 。

  • t1 线程 获得 A对象 锁，接下来想获取 B对象 的锁
  • t2 线程 获得 B对象 锁，接下来想获取 A对象 的锁

例：

@Slf4j(topic = "c.TestDeadLock")
public class TestDeadLock {
    public static void main(String[] args) {
        test1();
    }

    private static void test1() {
        Object A = new Object();
        Object B = new Object();

        Thread t1 = new Thread(() -> {
            synchronized (A) {
                log.debug("lock A");
                Sleeper.sleep(1);
                synchronized (B) {
                    log.debug("Lock B");
                    log.debug("操作...");
                }
            }
        },"t1");

        Thread t2 = new Thread(() -> {
            synchronized (B) {
                log.debug("lock B");
                Sleeper.sleep(1);
                synchronized (A) {
                    log.debug("Lock A");
                    log.debug("操作...");
                }
            }
        },"t2");

        t1.start();
        t2.start();
    }
}

/*Output:
21:57:21.183 c.TestDeadLock [t1] - lock A
21:57:21.183 c.TestDeadLock [t2] - lock B
...卡住
*/
定位死锁
  • 检测死锁可以使用 jconsole工具
  • 或者使用 jps 定位进程 id，再用 jstack 定位死锁
D:\java\IdeaProjects\concurrent>jps
19476 RemoteMavenServer36
21172
22132 TestDeadLock
22364 Launcher
23132 Jps

D:\java\IdeaProjects\concurrent>jstack 22132
2020-07-11 20:50:10
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000002f13800 nid=0x5988 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"t2" #12 prio=5 os_prio=0 tid=0x0000000019ee5800 nid=0x568c waiting for monitor entry [0x000000001a5ce000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.itcast.test.TestDeadLock.lambda$test1$1(TestDeadLock.java:33)
        - waiting to lock <0x00000000d6af5688> (a java.lang.Object)
        - locked <0x00000000d6af5698> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$2/1792845110.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"t1" #11 prio=5 os_prio=0 tid=0x0000000019ee4800 nid=0x19a4 waiting for monitor entry [0x000000001a4cf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.itcast.test.TestDeadLock.lambda$test1$0(TestDeadLock.java:22)
        - waiting to lock <0x00000000d6af5698> (a java.lang.Object)
        - locked <0x00000000d6af5688> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$1/897913732.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x00000000190d2000 nid=0x5ab8 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x0000000017bab800 nid=0x5418 runnable [0x000000001961e000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x00000000d6033b98> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x00000000d6033b98> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:61)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000017b63000 nid=0x594 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000003008000 nid=0x11a8 in Object.wait() [0x0000000018ebf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5e08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000d5e08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000017b3a000 nid=0x3070 in Object.wait() [0x0000000018dbf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5e06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000d5e06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x0000000017b17000 nid=0x44f8 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000002f29800 nid=0x59e8 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000002f2b000 nid=0x58e4 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000002f2c800 nid=0xe38 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002f2e000 nid=0xfa8 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x0000000019124000 nid=0x5370 waiting on condition

JNI global references: 316


Found one Java-level deadlock:
=============================
"t2":
  waiting to lock monitor 0x0000000017b3e3e8 (object 0x00000000d6af5688, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x0000000017b3f1a8 (object 0x00000000d6af5698, a java.lang.Object),
  which is held by "t2"

Java stack information for the threads listed above:
===================================================
"t2":
        at cn.itcast.test.TestDeadLock.lambda$test1$1(TestDeadLock.java:33)
        - waiting to lock <0x00000000d6af5688> (a java.lang.Object)
        - locked <0x00000000d6af5698> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$2/1792845110.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"t1":
        at cn.itcast.test.TestDeadLock.lambda$test1$0(TestDeadLock.java:22)
        - waiting to lock <0x00000000d6af5698> (a java.lang.Object)
        - locked <0x00000000d6af5688> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$1/897913732.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.


D:\java\IdeaProjects\concurrent>jps
14688 Jps
22544 Launcher
19476 RemoteMavenServer36
21172
23076 TestDeadLock

D:\java\IdeaProjects\concurrent>jstack 23076
2020-07-11 22:01:28
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000003653800 nid=0x55e8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"t2" #12 prio=5 os_prio=0 tid=0x000000001a30e000 nid=0x52ac waiting for monitor entry [0x000000001abdf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.itcast.test.TestDeadLock.lambda$test1$1(TestDeadLock.java:33)
        - waiting to lock <0x00000000d6af5628> (a java.lang.Object)
        - locked <0x00000000d6af5638> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$2/1792845110.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"t1" #11 prio=5 os_prio=0 tid=0x000000001a30d800 nid=0x5bdc waiting for monitor entry [0x000000001aadf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at cn.itcast.test.TestDeadLock.lambda$test1$0(TestDeadLock.java:22)
        - waiting to lock <0x00000000d6af5638> (a java.lang.Object)
        - locked <0x00000000d6af5628> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$1/897913732.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000019785800 nid=0x5370 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x0000000019705800 nid=0x1968 runnable [0x0000000019cde000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x00000000d6033628> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x00000000d6033628> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:61)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00000000182a0000 nid=0x1d2c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000000374d800 nid=0x55a0 in Object.wait() [0x00000000195df000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5e08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000d5e08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000001827a000 nid=0x4e2c in Object.wait() [0x00000000194de000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5e06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000d5e06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x0000000018257000 nid=0x4358 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000003669800 nid=0x5b50 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000366b000 nid=0x1374 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000366c800 nid=0x572c runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000366e000 nid=0x4d60 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x0000000019788000 nid=0x5870 waiting on condition

JNI global references: 316


Found one Java-level deadlock:
=============================
"t2":
  waiting to lock monitor 0x0000000003749a18 (object 0x00000000d6af5628, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x000000000374bb18 (object 0x00000000d6af5638, a java.lang.Object),
  which is held by "t2"

Java stack information for the threads listed above:
===================================================
"t2":
        at cn.itcast.test.TestDeadLock.lambda$test1$1(TestDeadLock.java:33)
        - waiting to lock <0x00000000d6af5628> (a java.lang.Object)
        - locked <0x00000000d6af5638> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$2/1792845110.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"t1":
        at cn.itcast.test.TestDeadLock.lambda$test1$0(TestDeadLock.java:22)
        - waiting to lock <0x00000000d6af5638> (a java.lang.Object)
        - locked <0x00000000d6af5628> (a java.lang.Object)
        at cn.itcast.test.TestDeadLock$$Lambda$1/897913732.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.
哲学家就餐问题

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JiS2c2Qf-1594825203210)(https://note.youdao.com/yws/api/personal/file/D4EC23F8C6F3466F9C38920F7F91B581?method=download&shareKey=1b9eb2b9c0ce067ffaba59ccd48767e6)]

有五位哲学家，围坐在圆桌旁。

  • 他们只做两件事，思考和吃饭，思考一会吃口饭，吃完饭后接着思考。
  • 吃饭时要用两根筷子吃，桌上共有 5 根筷子，每位哲学家左右手边各有一根筷子。
  • 如果筷子被身边的人拿着，自己就得等待

代码：

public class TestDeadLock {
    public static void main(String[] args) {
        Chopstick c1 = new Chopstick("1");
        Chopstick c2 = new Chopstick("2");
        Chopstick c3 = new Chopstick("3");
        Chopstick c4 = new Chopstick("4");
        Chopstick c5 = new Chopstick("5");
        new Philosopher("苏格拉底", c1, c2).start();
        new Philosopher("柏拉图", c2, c3).start();
        new Philosopher("亚里士多德", c3, c4).start();
        new Philosopher("赫拉克利特", c4, c5).start();
        new Philosopher("阿基米德", c5, c1).start();
    }
}

@Slf4j(topic = "c.Philosopher")
class Philosopher extends Thread {
    Chopstick left;
    Chopstick right;

    public Philosopher(String name, Chopstick left, Chopstick right) {
        super(name);
        this.left = left;
        this.right = right;
    }

    @Override
    public void run() {
        while (true) {
            //　尝试获得左手筷子
            synchronized (left) {
                // 尝试获得右手筷子
                synchronized (right) {
                    eat();
                }
            }
        }
    }

    private void eat() {
        log.debug("eating...");       // 吃饭
        Sleeper.sleep(0.5);         // 思考
    }
}

class Chopstick {
    String name;

    public Chopstick(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return "筷子{" + name + '}';
    }
}

执行不久就会卡住，使用 jconsole 检测死锁，发现：

------------------------------------------------------------------------
名称: 阿基米德
状态: cn.itcast.n4.deadlock.v1.Chopstick@7ca7f773上的BLOCKED, 拥有者: 苏格拉底
总阻止数: 4, 总等待数: 4

堆栈跟踪: 
cn.itcast.n4.deadlock.v1.Philosopher.run(TestDeadLock.java:42)
   - 已锁定 cn.itcast.n4.deadlock.v1.Chopstick@29a2fe14
------------------------------------------------------------------------
名称: 苏格拉底
状态: cn.itcast.n4.deadlock.v1.Chopstick@ac42a13上的BLOCKED, 拥有者: 柏拉图
总阻止数: 7, 总等待数: 2

堆栈跟踪: 
cn.itcast.n4.deadlock.v1.Philosopher.run(TestDeadLock.java:42)
   - 已锁定 cn.itcast.n4.deadlock.v1.Chopstick@7ca7f773
------------------------------------------------------------------------
名称: 柏拉图
状态: cn.itcast.n4.deadlock.v1.Chopstick@5a8cec41上的BLOCKED, 拥有者: 亚里士多德
总阻止数: 4, 总等待数: 1

堆栈跟踪: 
cn.itcast.n4.deadlock.v1.Philosopher.run(TestDeadLock.java:42)
   - 已锁定 cn.itcast.n4.deadlock.v1.Chopstick@ac42a13
------------------------------------------------------------------------
名称: 亚里士多德
状态: cn.itcast.n4.deadlock.v1.Chopstick@2a73ab22上的BLOCKED, 拥有者: 赫拉克利特
总阻止数: 9, 总等待数: 3

堆栈跟踪: 
cn.itcast.n4.deadlock.v1.Philosopher.run(TestDeadLock.java:42)
   - 已锁定 cn.itcast.n4.deadlock.v1.Chopstick@5a8cec41
------------------------------------------------------------------------
名称: 赫拉克利特
状态: cn.itcast.n4.deadlock.v1.Chopstick@29a2fe14上的BLOCKED, 拥有者: 阿基米德
总阻止数: 4, 总等待数: 1

堆栈跟踪: 
cn.itcast.n4.deadlock.v1.Philosopher.run(TestDeadLock.java:42)
   - 已锁定 cn.itcast.n4.deadlock.v1.Chopstick@2a73ab22

这种线程没有按预期结束，执行不下去的情况，归类为【活跃性】问题，除了死锁以外，还有活锁和饥饿者两种情况。

活锁

活锁出现在两个线程互相改变对方的结束条件，最后谁也无法结束，例如：

@Slf4j(topic = "c.TestLiveLock")
public class TestLiveLock {
    static volatile int count = 10;
    static final Object lock = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            // 期望减到 0 退出循环
            while (count > 0) {
                sleep(0.2);
                count--;
                log.debug("count: {}", count);
            }
        }, "t1").start();
        
        new Thread(() -> {
            // 期望超过 20 退出循环
            while (count < 20) {
                sleep(0.2);
                count++;
                log.debug("count: {}", count);
            }
        }, "t2").start();
    }
}

互相改变对方的结束条件，可能永远不会结束。

解决：尽量让他们的执行时间交错，例如增加随机睡眠时间。

饥饿

很多教程中把饥饿定义为，一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束，饥饿的情况不易演示，使用读写锁时会涉及饥饿问题。

解决：通过ReentrantLock

saltedfishust
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
jconsole使用手册
11-28
jconsole使用手册，用于监控java运行状态，线程数，进程数，对象，jvm内存信息，时间等性能
jconsole线程面板中的阻塞总数和等待总数(转)
zy103118的博客
07-12 2114
jconsole线程面板中的阻塞总数和等待总数(转)
高并发编程：7、synchronized
oJueQiang123456的博客
07-14 746
一、概述 synchronized可以保证方法或者代码块在运行时，同一时刻只有一个方法可以进入到临界区，同时它还可以保证共享变量的内存可见性。 多线程访问synchronized方法或代码块时，变成了单线程串行的方式。 二、基本认识 package com.cfl.thread; public class Thread7 { private final static Object...
jconsole 解决线程假死问题
淡水河边
09-18 1473
      最近在做一个基于多线程的网络抓取，运行过程中总是假死，为此我给线程增加了超时安全退出，但是仍旧没有解决这个问题。后来想了一下，应该有相关的JVM问题定位工具，搜索了一下相关内容，发现jconsole可以考虑尝试一下。 1. jconsole 是什么？      从Java 5开始 引入了 JConsole。JConsole 是一个内置 Java 性能分析器，可以从命令行或在 G...
线程死锁
huahua168168357的博客
04-22 757
我们知道线程长时间停顿的主要原因有：等待外部资源（数据库连接、网络资源、设备资源等）、死循环、锁等待（死锁和活锁）。现在写一个线程死锁的小Demo，就我自己的理解就是：线程t1先锁定一个对象A，再锁定对象B。而线程t2先锁定对象B，再锁定对象A。当线程t1先执行时，并没有释放锁对象B，但是线程t2要锁定对象B（线程t1并没有释放锁），同理，要是线程t2先执行，并没有释放锁对象A，但是线程t1要锁定对
Java线程之活跃性危险.docx
06-21
Java线程中的活跃性危险主要涉及线程的执行与资源竞争，这可能引发死锁、饥饿、长时间不响应以及活锁等现象。这些情况都可能导致系统性能下降甚至完全停止。 **1. 死锁** 死锁是由于线程间的资源竞争和锁的顺序不当...
java并发之原子操作类和非阻塞算法
08-26
在使用非阻塞算法时，需要注意活跃性问题，如死锁、活锁和饥饿现象。非阻塞算法的目标是即使在某些线程出现问题时，其他线程仍能继续执行，确保系统的整体活性。无锁算法是其中的一种，它确保在任何时候至少有一个...
最热门的Java 面试题汇总
04-26
24. **并发编程常见问题**：包括死锁、活锁、饥饿、竞态条件等。 25. **并发与并行**：并发是多个任务交替执行，共享资源；并行是多个任务同时执行，不共享资源。 26. **进程与线程**：进程是资源分配的最小单位，...
lab-concurrente:本课题并发与并行程序设计的实验室实践
07-11
`lab-concurrente`这个实验室实践可能包含了创建、管理和同步线程的相关练习，以及对死锁、活锁和饥饿等并发问题的分析。 并行编程则更进一步，它是指多个执行单元在同一时间执行不同的任务。在多核处理器环境下，...
leetcode赛车-Concurrency:#JAVA#并发
07-01
最常见的一种活性问题，死锁，以及另外两种活性问题，饥饿和活锁。 僵局 死锁描述了两个或多个线程被永远阻塞、互相等待的情况。 饥饿 饥饿描述了线程无法定期访问共享资源并且无法取得进展的情况。 当共享资源被...
Java应用程序监控之 jconsole
top_explore的博客
07-13 788
jconsole jconsole 启动一个图形控制台，使您可以监视和管理Java应用程序。JConsole图形用户界面是一个符合Java Management Extensions（JMX）规范的监视工具。JConsole使用Java虚拟机（Java VM）的广泛工具来提供有关Java平台上运行的应用程序的性能和资源消耗的信息。 启动JConsole 该JConsole的可执行文件中可以找...
jconsole监控死锁
csdn问鼎
08-09 1189
1.示例代码  public class TestDeadLock { public static void main(String[] args) { for (int i = 0; i &lt; 100; i++) { new Thread(new SynThread(1, 2)).start(); new Thr...
锁的活跃性(死锁、活锁、饥饿)
我的博客
09-16 317
死锁 锁是个非常有用的工具，运用场景非常多，它使用起来非常简单，而且易于理解。但 同时它也会带来一些困扰，那就是可能会引起死锁，一旦产生死锁，就会造成系统功能不可 用。 定义 线程死锁是指由于两个或者多个线程互相持有对方所需要的资源，会互相等待对方释放资源，如果线程都不主动释放所占有的资源，将产生死锁。 死锁的产生的一些特定条件： 1、互斥条件：即一个资源只能被一个线程占用，直到被该线程释放 。 2、请求和保持条件：一个线程因请求资源而发生阻塞时，对已获得的资源保持不放。 3、不剥夺条件：一个资源被一个线程
深入理解JVM（一）
kk的博客
09-22 450
目录 第一章 jvm概述 一 知识点体系 二、 jdk, jre, jvm的关系 三、内存溢出场景模拟 四、jvm性能监控场景模拟 第二章 一、 Java的历史版本 二、1.8的新特性 三、Java 虚拟机的发展 第三章 - java 五大 内存区域 一、jvm内存 二、java 内存区域 - 程序计数器 - 行号 三、java 内存区域 - java虚拟机栈- 存放栈...
哲学家就餐问题
Mrrr_Li的博客
11-24 505
问题图示 题目解释 有五位哲学家，围坐在圆桌旁。 ● 他们只做两件事，思考和吃饭，思考一会吃口饭，吃完饭后接着思考。 ● 吃饭时要用两根筷子吃，桌上共有 5 根筷子，每位哲学家左右手边各有一根筷子。 ● 如果筷子被身边的人拿着，自己就得等待 5根筷子对于5个哲学家线程来说是共享资源，需要加锁。不发生死锁的情况是有一个线程成功吃饭思考后，释放两个筷子的锁，然后哲学家再竞争筷子吃饭。发生死锁的情况是5个哲学家各锁住了一根筷子，都无法获...
jconsole线程面板中的阻塞总数和等待总数
热门推荐
12-27 1万+
http://blog.csdn.net/mangmang2012/article/details/7106692 阻塞总数 Blocked count is the total number of times that the thread blocked to enter or reenter a monitor. I.e. the number of times a thread h
锁活跃性问题（死锁，饥饿、活锁）
l1394049664的博客
07-29 1205
一、死锁         每个人都拥有其他人需要的资源，同时又等待其他人已经拥有的资源，并且每个人在获取所有需要的资源之前都不会放弃已经拥有的资源。         当一个线程永远地持有一个锁，并且其他线程都尝试去获得这个锁时，那么它们将永远被阻塞，这个我们都知道。如果线程A持有锁L并且想获得锁M，线程B持有锁M并且想获得锁L，那么这两个线程将永远等待下去，这种情况就是最简单的死锁形式。其中多...
理理并发：死锁，活锁与饥饿
erlang_boy
06-30 248
一、并发问题的产生 若多个cpu需要对同一内存地址中的数据，进行增删改查，必须按先来后到的顺序进行。保证不了顺序，程序就会出现问题。这就是所谓的竞争条件 race condition 二、并发问题的场景 先跑个程序看看： func main() { runtime.GOMAXPROCS(1) // P的值 var data = 0 access := func(i int) { ...
java死锁与活锁以及饥饿案例
最新发布
03-03
Java中的死锁和活锁是多线程并发编程中的常见问题，这些问题可能会导致线程无法向前执行或陷入死循环。下面分别介绍Java中死锁和活锁的概念和案例。 1. 死锁 死锁是指两个或多个线程相互等待对方释放锁，从而导致...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值