2. 程式人生 > >Java執行緒之如何分析死鎖及避免死鎖

Java執行緒之如何分析死鎖及避免死鎖

阿新 • • 發佈：2019-01-22

在這裡插入圖片描述

什麼是死鎖

java中的死鎖是一種程式設計情況，其中兩個或多個執行緒被永久阻塞，Java死鎖情況出現至少兩個執行緒和兩個或更多資源。
在這裡，我們將寫了一個簡單的程式，它將導致java死鎖場景，然後我們將分析它。

怎麼實現死鎖

下面我們一起看一個簡單的死鎖事例,在主執行緒中每隔5秒鐘啟動一個執行緒，每個執行緒的執行時間是3秒鐘

package com.lkf.mulithread;

public class ThreadDeadlock {
    public static void main(String[] args) throws InterruptedException {
        Object obj1 = new Object();
        Object obj2 = new Object();
        Object obj3 = new Object();

        Thread t1 = new Thread(new SyncThread(obj1, obj2), "t1");
        Thread t2 = new Thread(new SyncThread(obj2, obj3), "t2");
        Thread t3 = new Thread(new SyncThread(obj3, obj1), "t3");

        t1.start();
        Thread.sleep(5000);
        t2.start();
        Thread.sleep(5000);
        t3.start();

    }

}

class SyncThread implements Runnable{
    private Object obj1;
    private Object obj2;

    public SyncThread(Object o1, Object o2){
        this.obj1=o1;
        this.obj2=o2;
    }
    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + " acquiring lock on "+obj1);
        synchronized (obj1) {
            System.out.println(name + " acquired lock on "+obj1);
            work();
            System.out.println(name + " acquiring lock on "+obj2);
            synchronized (obj2) {
                System.out.println(name + " acquired lock on "+obj2);
                work();
            }
            System.out.println(name + " released lock on "+obj2);
        }
        System.out.println(name + " released lock on "+obj1);
        System.out.println(name + " finished execution.");
    }
    private void work() {
        try {
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

執行結果：

t1 acquiring lock on [email protected]
t1 acquired lock on [email protected]
t2 acquiring lock on [email protected]
t2 acquired lock on [email protected]
t3 acquiring lock on [email protected]
t3 acquired lock on [email protected]
t1 acquiring lock on [email protected]
 

t2 acquiring lock on [email protected]
t3 acquiring lock on [email protected]

可以看到每個執行緒中都能成功獲取第一個物件的鎖，最終卻阻塞在了獲取第二個物件，造成了執行緒之間的互相等待，形成了死鎖

怎麼排查死鎖

我們通過jstack拿到該應用程式死鎖的執行緒轉儲檔案如下（獲取執行緒轉儲檔案方法）：


2018-03-31 15:33:34
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode):

"RMI TCP Connection(2)-192.168.1.101" #22 daemon prio=9 os_prio=31 tid=0x00007fe2c81cc000 nid=0xa503 runnable [0x000070000ba7c000]
   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 java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
        - locked <0x0000000797612b30> (a java.io.BufferedInputStream)
        at java.io.FilterInputStream.read(FilterInputStream.java:83)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$6/556824457.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - <0x0000000797612c78> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"JMX server connection timeout 21" #21 daemon prio=9 os_prio=31 tid=0x00007fe2c8968800 nid=0xa703 in Object.wait() [0x000070000b97a000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
        - locked <0x0000000797600720> (a [I)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"RMI Scheduler(0)" #20 daemon prio=9 os_prio=31 tid=0x00007fe2c81bc800 nid=0xa903 waiting on condition [0x000070000b877000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x0000000797618010> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"RMI TCP Connection(1)-192.168.1.101" #19 daemon prio=9 os_prio=31 tid=0x00007fe2c884e000 nid=0x5903 runnable [0x000070000b773000]
   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 java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
        - locked <0x0000000797600eb8> (a java.io.BufferedInputStream)
        at java.io.FilterInputStream.read(FilterInputStream.java:83)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$6/556824457.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - <0x0000000797600ff8> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"RMI TCP Accept-0" #18 daemon prio=9 os_prio=31 tid=0x00007fe2c8855000 nid=0x5703 runnable [0x000070000b671000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
        at java.net.ServerSocket.implAccept(ServerSocket.java:545)
        at java.net.ServerSocket.accept(ServerSocket.java:513)
        at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
        at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400)
        at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"DestroyJavaVM" #16 prio=5 os_prio=31 tid=0x00007fe2c90cf800 nid=0x2803 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"t3" #14 prio=5 os_prio=31 tid=0x00007fe2c7865000 nid=0x5503 waiting for monitor entry [0x000070000b56e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x0000000797618188> (a java.lang.Object)
        - locked <0x0000000797618198> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"Attach Listener" #15 daemon prio=9 os_prio=31 tid=0x00007fe2c884d800 nid=0xb07 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"t2" #13 prio=5 os_prio=31 tid=0x00007fe2c884b800 nid=0x3e03 waiting for monitor entry [0x000070000b368000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x0000000797618198> (a java.lang.Object)
        - locked <0x00000007976181e8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"t1" #12 prio=5 os_prio=31 tid=0x00007fe2c7885000 nid=0x4103 waiting for monitor entry [0x000070000b265000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x00000007976181e8> (a java.lang.Object)
        - locked <0x0000000797618188> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"Service Thread" #11 daemon prio=9 os_prio=31 tid=0x00007fe2c884c800 nid=0x4503 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C1 CompilerThread2" #10 daemon prio=9 os_prio=31 tid=0x00007fe2c906c000 nid=0x4603 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread1" #9 daemon prio=9 os_prio=31 tid=0x00007fe2c884a800 nid=0x3c03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread0" #8 daemon prio=9 os_prio=31 tid=0x00007fe2c806c800 nid=0x3a03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"JDWP Command Reader" #7 daemon prio=10 os_prio=31 tid=0x00007fe2c7811000 nid=0x4903 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"JDWP Event Helper Thread" #6 daemon prio=10 os_prio=31 tid=0x00007fe2c7810000 nid=0x3803 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"JDWP Transport Listener: dt_socket" #5 daemon prio=10 os_prio=31 tid=0x00007fe2c780f800 nid=0x4a07 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fe2c7820800 nid=0x3003 in Object.wait() [0x000070000a847000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000797618850> (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)

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=31 tid=0x00007fe2c8014800 nid=0x5303 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fe2c8011800 nid=0x1b07 runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fe2c8012000 nid=0x1d03 runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fe2c8012800 nid=0x2a03 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fe2c9010000 nid=0x5403 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fe2c781a000 nid=0x4303 waiting on condition 

JNI global references: 5038


Found one Java-level deadlock:
=============================
"t3":
  waiting to lock monitor 0x00007fe2c91c7198 (object 0x0000000797618188, a java.lang.Object),
  which is held by "t1"
"t1":
  waiting to lock monitor 0x00007fe2c9046568 (object 0x00000007976181e8, a java.lang.Object),
  which is held by "t2"
"t2":
  waiting to lock monitor 0x00007fe2c91c5b98 (object 0x0000000797618198, a java.lang.Object),
  which is held by "t3"

Java stack information for the threads listed above:
===================================================
"t3":
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x0000000797618188> (a java.lang.Object)
        - locked <0x0000000797618198> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"t1":
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x00000007976181e8> (a java.lang.Object)
        - locked <0x0000000797618188> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"t2":
        at com.lkf.mulithread.SyncThread.run(ThreadDeadlock.java:40)
        - waiting to lock <0x0000000797618198> (a java.lang.Object)
        - locked <0x00000007976181e8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

為了分析死鎖，我們需要注意那些被阻塞的執行緒，以及等待鎖定的資源，每個資源有一個惟一的ID，我們可以找到哪個執行緒已經持有物件上的鎖，比如：執行緒t3正在等待獲取物件0x00007fe2c91c7198的鎖，但是該物件已經被執行緒t1鎖定。

怎麼避免死鎖

上邊，我們分析了死鎖的情況，發現了導致死鎖的執行緒，我們需要修改程式碼以避免死鎖的情況，那麼怎麼避免死鎖呢

1、避免巢狀鎖

這是死鎖最常見的原因，如果您已經持有一個資源，請避免鎖定另一個資源。如果只使用一個物件鎖，則幾乎不可能出現死鎖情況，比如以下程式碼對上邊的迴圈巢狀部分進行修改，則避免了死鎖的情況：

public void run() {
        String name = Thread.currentThread().getName();
        System.out.println(name + " acquiring lock on " + obj1);
        synchronized (obj1) {
            System.out.println(name + " acquired lock on " + obj1);
            work();
        }
        System.out.println(name + " released lock on " + obj1);
        System.out.println(name + " acquiring lock on " + obj2);
        synchronized (obj2) {
            System.out.println(name + " acquired lock on " + obj2);
            work();
        }
        System.out.println(name + " released lock on " + obj2);

        System.out.println(name + " finished execution.");
    }

2、只鎖需要的部分

只獲對需要的資源加鎖，例如在上面的程式中，我們鎖定了完整的物件資源，但是如果我們只需要其中一個欄位，那麼我們應該只鎖定那個特定的欄位而不是完整的物件

3、避免無限期等待

如果兩個執行緒使用 thread join 無限期互相等待也會造成死鎖，我們可以設定等待的最大時間來避免這種情況。

相關推薦

Java執行緒之如何分析死鎖及避免死鎖

什麼是死鎖 java中的死鎖是一種程式設計情況，其中兩個或多個執行緒被永久阻塞，Java死鎖情況出現至少兩個執行緒和兩個或更多資源。 在這裡，我們將寫了一個簡單的程式，它將導致java死鎖場景，然後我們將分析它。 怎麼實現死鎖 下面我們一起看一個簡單的死鎖事例

Java問題定位之Java執行緒堆疊分析

"main" prio=1 tid=0x0805c988 nid=0xd28 runnable [0xfff65000..0xfff659c8] at java.lang.String.indexOf(String.java:1352) at java.io.PrintStream.write

Java執行緒之釋放鎖，釋放資源，釋放CPU

多執行緒中的wait與sleep到底誰釋放了鎖 首先，多執行緒中會使用到兩個延遲的函式，wait和sleep。 wait是Object類中的方法，而sleep是Thread類中的方法。 sleep是Thread類中的靜態方法。無論是在a執行緒中呼叫b的sl

java 執行緒之執行緒狀態

java執行緒狀態 1. 初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。 2. 執行(RUNNABLE)： Java執行緒中將就緒（ready）和執行中（running）兩種狀態籠統的稱為“執行”。 執行緒物件建立後，其他執行緒(比如main執行緒）呼叫了該物件

Java執行緒之semaphore和Exchanger

Semaphore是Java執行緒的一個計數訊號量。我們可用於多執行緒的併發訪問控制。 就像我們常見的執行緒池，資料庫連線池就可以使用Semaphore進行邏輯的實現。Semaphore中我們就介紹兩個最常用的兩個方法。 acquire() 從Semaphore獲取許可，如果計數不小於0

Java執行緒的6種狀態及切換

原文：https://blog.csdn.net/pange1991/article/details/53860651#commentBox Java中執行緒的狀態分為6種。     1. 初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。

Java執行緒之非同步回撥(Callback)

●介紹      有時候執行一個任務需要很長時間，單執行緒下執行緒會處於阻塞狀態。這個時候我們會考慮一種非阻塞的處理模式。非阻塞任務在任何程式語言裡都必不可少，Java也不例外。多執行緒就是一個很好的解決辦法。     

Java執行緒的6種狀態及切換(透徹講解)-本文系轉載

Java執行緒的6種狀態及切換(透徹講解) 轉自：https://mp.weixin.qq.com/s/hUOwck4lMp7c_rvY4TTeQQ Java中執行緒的狀態分為6種。 1.  初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。

java執行緒之Latch設計模式見解

CountDownLatch :（個人理解）使用閥門值，直到閥門值為０之前，一直阻塞執行緒。實則使用物件鎖，不釋放物件鎖，一直佔用資源，（這裡是一個缺點）。閥門值為０時，呼叫釋放物件鎖的方法，釋放資源。應用的場景，我覺得是需要一些執行緒先完成的前提下，再使用其他執行緒。也就是我就是要一些重要的執行緒

Java執行緒的6種狀態及切換（透徹講解）

來源：https://blog.csdn.net/pange1991/article/details/53860651 Java中執行緒的狀態分為6種。 1.初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。 2.執行(RUNNABLE)：J

Java執行緒的6種狀態及切換(透徹講解)

Java中執行緒的狀態分為6種。 1. 初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。 2. 執行(RUNNABLE)：Java執行緒中將就緒（ready）和執行中（running）兩種

Java執行緒之Synchronized同步————Java學習之路(17)

前言——不進則退啊，部落格幾天沒寫，排名第一次下降了，得勤奮更新，不能偷懶。。 歡迎轉載，轉載請註明來處。 目錄 一.演示同步問題 此前，我們用的多執行緒都是較為簡單的例子，都沒有涉及到多個執行緒共享同一個物件或者資源的情況。倘若多執行緒共享資

Java執行緒之訊號量

 計數訊號量用來控制同時訪問某個特定資源的運算元量，或者同時執行某個指定操作的數量。計數訊號量還可以用來實現某種資源池，或者對容器施加邊界。  Semaphore中管理者一組虛擬的許可，許可的數量可通過建構函式來指定。在互相操作時可以首先獲得許可（只要還有剩餘的許可），並在使用以後釋放許可。

Java執行緒之閉鎖

 閉鎖是一種同步工具類，可以延遲執行緒的進度直到其到達終止狀態。閉鎖的作用相當於一扇門：在閉鎖到達結束狀態之前，這扇門一直是關閉的，並且沒有任何執行緒能通過，當到達結束狀態時，這扇門會開啟並允許所有的執行緒通過。當閉鎖到達結束狀態後，將不會再改變狀態，因此這扇門將永遠保持開啟狀態。閉鎖可以用

java執行緒之Executor框架與執行緒池

執行緒雖然在web開發中用的不算特別多，但在特定的情況下還是能發揮重要重要作用的，因此即使用的少還是掌握下比較好；下面先回顧下比較執行緒的常規實現方法 1 繼承Thread類 2 實現runnable介面（使用較多） java5之後有了新的執行緒實現方式，java5可以使用

Java執行緒的5種狀態及狀態之間轉換

Thread.sleep(long millis)，一定是當前執行緒呼叫此方法，當前執行緒進入阻塞，但不釋放物件鎖，millis後執行緒自動甦醒進入可執行狀態。作用：給其它執行緒執行機會的最佳方式。Thread.yield()，一定是當前執行緒呼叫此方法，當前執行緒放棄獲取的cpu時間片，由執行狀態變會可執行

Java執行緒的6種狀態及切換（生命週期）

轉自：https://blog.csdn.net/pange1991/article/details/53860651/ Java中執行緒的狀態分為6種。 1. 初始(NEW)：新建立了一個執行緒物件，但還沒有呼叫start()方法。2. 執行(RUNNABLE)：Java執行緒中將就緒（r

多執行緒之訊號量Semaphore及原理

一、訊號量（Semaphore） 重入鎖ReentrantLock是獨佔模式，一次都只允許一個執行緒訪問一個資源，而訊號量是共享模式，也就是說可以指定多個執行緒，同時訪問某一個資源。 Semaphore的兩個構造方法： public Semaphore(int pe

Java執行緒之銀行存取款

銀行的存取款可以分為存款和取款： 當去存款的時候會先顯示賬戶資訊，然後將存進去的錢和賬戶原有的錢數相加，返回存款之後賬戶資訊； 當去取款的時候會先顯示賬戶資訊，然後將取錢數和賬戶裡面的錢相對比，如果取

Java執行緒之執行緒池的使用

 在Java中進行非同步操作時，執行緒必不可少，但如果頻繁的建立、銷燬一個執行緒，這是很耗效能的，所以執行緒池就應運而生了，Java中主要有newFixedThreadPool、newCachedThreadPool、newSingleThreadExecuter及newSchedule