Ⅰ java線程狀態中BLOCKED和WAITING有什麼區別
一、線程5種狀態新建狀態（New） 新創建了一個線程對象。就緒狀態（Runnable） 線程對象創建後，其他線程調用了該對象的start()方法。該狀態的線程位於可運行線程池中，變得可運行，等待獲取CPU的使用權。運行狀態（Running） 就緒狀態的線程獲取了CPU，執行程序代碼。阻塞狀態（Blocked） 阻塞狀態是線程因為某種原因放棄CPU使用權，暫時停止運行。直到線程進入就緒狀態，才有機會轉到運行狀態。阻塞的情況分三種：等待阻塞：運行的線程執行wait()方法，JVM會把該線程放入等待池中。同步阻塞：運行的線程在獲取對象的同步鎖時，若該同步鎖被別的線程佔用，則JVM會把該線程放入鎖池中。其他阻塞：運行的線程執行sleep()或join()方法，或者發出了I/O請求時，JVM會把該線程置為阻塞狀態。當sleep()狀態超時、join()等待線程終止或者超時、或者I/O處理完畢時，線程重新轉入就緒狀態。死亡狀態（Dead）：線程執行完了或者因異常退出了run()方法，該線程結束生命周期。二、Jstack中常見的線程狀態應用程序啟動後，我們對系統運行狀況的觀測大部分情況下是通過運行日誌。但是若某一天發現，日誌中記錄的行為與預想的不一致，此時需要進一步的系統監控該怎麼辦，Jstack是常用的排查工具，它能輸出在某一個時間，Java進程中所有線程的狀態，很多時候這些狀態信息能給我們的排查工作帶來有用的線索。
Jstack的輸出中，Java線程狀態主要是以下幾種：RUNNABLE 線程運行中或I/O等待
BLOCKED 線程在等待monitor鎖(synchronized關鍵字)
TIMED_WAITING 線程在等待喚醒，但設置了時限WAITING 線程在無限等待喚醒1） 讓線程一直處於RUNNABLE
<pre t="code" l="java">public static void runnable() {
long i = 0;
while (true) {
i++;
}
}2) 讓線程一直處於BLOCKED
<pre t="code" l="java">public static void blocked() {
final Object lock = new Object();
new Thread() {
public void run() {
synchronized (lock) {
System.out.println("i got lock, but don't release");
try {
Thread.sleep(1000L * 1000);
} catch (InterruptedException e) {
}
}
}
}.start();
try { Thread.sleep(100); } catch (InterruptedException e) {}
synchronized (lock) {
try {
Thread.sleep(30 * 1000);
} catch (InterruptedException e) {
}
}
}主線程sleep，先讓另外一個線程拿到lock，並長期持有lock（sleep會持有鎖，wait不會）。此時主線程會BLOCK住等待lock被釋放，此時jstack的輸出可以看到main線程狀態是BLOCKED。這里要注意的是只有synchronized這種方式的鎖（monitor鎖）才會讓線程出現BLOCKED狀態，等待ReentrantLock則不會。
3) 讓線程處於TIMED_WAITING狀態<pre t="code" l="java">public static void timedWaiting() {
final Object lock = new Object();
synchronized (lock) {
try {
lock.wait(30 * 1000);
} catch (InterruptedException e) {
}
}
}<pre t="code" l="java">
4)讓線程處於WAITING狀態<pre t="code" l="java">public static void waiting() {
final Object lock = new Object();
synchronized (lock) {
try {
lock.wait();
} catch (InterruptedException e) {
}
}
}無超時的等待，必須等待lock.notify()或lock.notifyAll()或接收到interrupt信號才能退出等待狀態。
<pre t="code" l="java">
<pre t="code" l="java">
Ⅱ BLOCKED 狀態的線程到底會不會算入load
最近在做線程mp分析的一個工具，因而比較關注java線程的狀態，現在比較疑惑的一個問題是處於BLOCKED (on object monitor) 狀態的線程到底會不會算入到load里，也就是處於這個狀態的線程會不會是runnable隊列里的線程 注意到ObjectMonitor::enter(TRAPS)這個方法，設置線程處於BLOCKED狀態的代碼是 jtbmes(jt, this);這行代碼 (JavaThread *java_thread, ObjectMonitor *obj_m) : JavaThreadStatusChanger(java_thread) { assert((java_thread != NULL), "Java thread should not be null here"); // Change thread status and collect contended enter stats for monitor contended // enter done for external java world objects and it is contended. All other cases // like for vm internal objects and for external objects which are not contended // thread status is not changed and contended enter stat is not collected. _active = false; if (is_alive() && ServiceUtil::visible_oop((oop)obj_m->object()) && obj_m->contentions() > 0) { _stat = java_thread->get_thread_stat(); _active = contended_enter_begin(java_thread); } } static bool contended_enter_begin(JavaThread *java_thread) { set_thread_status(java_thread, java_lang_Thread::BLOCKED_ON_MONITOR_ENTER); ThreadStatistics* stat = java_thread->get_thread_stat(); stat->contended_enter(); bool active = ThreadService::is_thread_monitoring_contention(); if (active) { stat->contended_enter_begin(); } return active; } 同時注意到在後面有 EnterI (THREAD) ;這行代碼，其實現里有個for循環 for (;;) { if (TryLock (Self) > 0) break ; assert (_owner != Self, "invariant") ; if ((SyncFlags & 2) && _Responsible == NULL) { Atomic::cmpxchg_ptr (Self, &_Responsible, NULL) ; } // park self if (_Responsible == Self || (SyncFlags & 1)) { TEVENT (Inflated enter - park TIMED) ; Self->_ParkEvent->park ((jlong) RecheckInterval) ; // Increase the RecheckInterval, but clamp the value. RecheckInterval *= 8 ; if (RecheckInterval > 1000) RecheckInterval = 1000 ; } else { TEVENT (Inflated enter - park UNTIMED) ; Self->_ParkEvent->park() ; } if (TryLock(Self) > 0) break ; // The lock is still contested. // Keep a tally of the # of futile wakeups. // Note that the counter is not protected by a lock or updated by atomics. // That is by design - we trade "lossy" counters which are exposed to // races ring updates for a lower probe effect. TEVENT (Inflated enter - Futile wakeup) ; if (ObjectMonitor::_sync_FutileWakeups != NULL) { ObjectMonitor::_sync_FutileWakeups->inc() ; } ++ nWakeups ;
Ⅲ java web ajax 請求被堵塞
web伺服器的問題，後台看看，主要查查以下幾個方面：
1、程序寫法是不是有問題；
2、應用框架本身有么有問題（比如struts2有些版本有問題，升級就好了）；
3、全面對系統進行優化，配置可用資源；
4、如果是調用其他系統的話，有可能的話對其進行調優或架構集群環境
Ⅳ java怎麼判斷線程中斷
方法一、程正常執行完畢，正常結束。也就是讓run方法執行完畢，該線程就會正常結束。
方法二、監視某些條件，結束線程的不間斷運行。然而，通常有些線程是伺服線程，它們往往需要長時間的運行，只有在外部某些條件滿足的情況下，才能關閉這些線程。一般情況下，它們執行在一個while(true)的死循環中。如:@Overridepublicvoid run() {while(true){someWork();if(finished){break;}try {Thread.sleep(10000);} catch (InterruptedException e) {/* TODO自動生成 catch 塊**/e.printStackTrace();}}}我們可以在while死循環內，每次循環時，察看外部條件，看看是否需要關閉當前線程。如果是，就break，跳出死循環，或者是拋出異常，跳出死循環，結束線程。
方法三、捕獲InterruptedException 運行時異常，中斷當前線程。有些執行伺服任務的線程，在while(true)這樣的死循環內部，是一個阻塞中的方法。此時，就不能採用第二種方法了。因為，當該方法沒有返回時，該線程會一直處於阻塞當中，根本無法執行其他語句。這時候就需要調用該線程的interrupt方法，產生一個InterruptedException運行時異常，是阻塞中的那個方法拋出這個異常，從而讓我們有機會結束這個線程的執行。如：@Overridepublicvoid run() {while(true){try {// getSendMessages 是BlockingQueue類。它的take方法將會阻塞!responseMessage = this.getSendMessages().take();} catch (InterruptedException e1) {thrownew RuntimeException();//或者break;}someWork();}一個外部的Thread 對象 指向這個線程。 需要結束這個線程時，只需要調用thread對象的interrupt() 方法，就會在responseMessage = this.getSendMessages().take();這條語句中產生一個InterruptedException異常，從而結束該線程的阻塞狀態，通過拋出異常，或者break跳出死循環，結束這個線程。以上所介紹的便是Java中斷線程的基本方法，也從安全形度出發所提倡的三種中斷線程的方法，希望予以正確引用
Ⅳ was blocked e to mime type mismatch 怎麼解決
was blocked e to mime type mismatch
詞典結果
was blocked e to mime type mismatch
由於MIME類型不匹配的封鎖
Ⅵ java線程的幾種狀態
總結了6種狀態，希望對你所有幫助：
1、NEW狀態是指線程剛創建, 尚未啟動
2、RUNNABLE狀態是線程正在正常運行中, 當然可能會有某種耗時計算/IO等待的操作/CPU時間片切換等, 這個狀態下發生的等待一般是其他系統資源, 而不是鎖, Sleep等
3、BLOCKED這個狀態下, 是在多個線程有同步操作的場景, 比如正在等待另一個線程的synchronized 塊的執行釋放, 或者可重入的 synchronized塊里別人調用wait() 方法, 也就是這里是線程在等待進入臨界區
4、WAITING這個狀態下是指線程擁有了某個鎖之後, 調用了他的wait方法, 等待其他線程/鎖擁有者調用 notify / notifyAll 一遍該線程可以繼續下一步操作, 這里要區分 BLOCKED 和 WATING 的區別, 一個是在臨界點外面等待進入, 一個是在臨界點裡面wait等待別人notify, 線程調用了join方法 join了另外的線程的時候, 也會進入WAITING狀態, 等待被他join的線程執行結束
5、TIMED_WAITING這個狀態就是有限的(時間限制)的WAITING, 一般出現在調用wait(long), join(long)等情況下, 另外一個線程sleep後, 也會進入TIMED_WAITING狀態
6、TERMINATED這個狀態下表示 該線程的run方法已經執行完畢了, 基本上就等於死亡了(當時如果線程被持久持有, 可能不會被回收)
Ⅶ Java線程狀態中BLOCKED跟WAITING有什麼區別
BLOCKED狀態
線程處於BLOCKED狀態的場景。
當前線程在等待一個monitor lock，比如等待執行synchronized代碼塊或者使用synchronized標記的方法。
在synchronized塊中循環調用Object類型的wait方法，如下是樣例
synchronized(this)
{
while (flag)
{
obj.wait();
}
// some other code
}
WAITING狀態
線程處於WAITING狀態的場景。
調用Object對象的wait方法，但沒有指定超時值。
調用Thread對象的join方法，但沒有指定超時值。
調用LockSupport對象的park方法。
提到WAITING狀態，順便提一下TIMED_WAITING狀態的場景。
TIMED_WAITING狀態
線程處於TIMED_WAITING狀態的場景。
調用Thread.sleep方法。
調用Object對象的wait方法，指定超時值。
調用Thread對象的join方法，指定超時值。
調用LockSupport對象的parkNanos方法。
調用LockSupport對象的parkUntil方法。
Ⅷ java線程運行怎麼有第六種狀態
其實線程只有"就緒"、"阻塞"、"運行"三種狀態：
1. 運行狀態，線程正在幹活的狀態
2. 就緒狀態，CPU正在忙活別的，線程搖晃著一個"恭候您光臨"的小旗子的狀態
3. 阻塞狀態，線程主動讓出CPU資源，搖晃著一個"我這會還不能出台您稍後再來"的小旗子的狀態
"新建"和"終止"這兩種狀態其實並不是線程的狀態，而是java.lang.Thread對象的狀態。可以說，處於"新建"和"終止"狀態的"線程"其實並不是線程，而只是一個代表著線程對象而已。
所以我們把"新建(NEW)"和"終止(TERMINATED)"兩種狀態去掉，那麼Java定義的線程狀態還有4種：
1. RUNNABLE
2. BLOCKED
3. WAITING
4. TIMED_WAITING
這四種狀態怎麼對應到"就緒"、"阻塞"、"運行"這三種狀態里呢：
1. RUNNABLE，對應"就緒"和"運行"兩種狀態，也就是說處於就緒和運行狀態的線程在java.lang.Thread中都表現為"RUNNABLE"
2. BLOCKED，對應"阻塞"狀態，此線程需要獲得某個鎖才能繼續執行，而這個鎖目前被其他線程持有，所以進入了被動的等待狀態，直到搶到了那個鎖，才會再次進入"就緒"狀態
3. WAITING，對應"阻塞"狀態，代表此線程正處於無限期的主動等待中，直到有人喚醒它，它才會再次進入就緒狀態
4. TIMED_WAITING，對應"阻塞"狀態，代表此線程正處於有限期的主動等待中，要麼有人喚醒它，要麼等待夠了一定時間之後，才會再次進入就緒狀態
Ⅸ Java線程中wait狀態和block狀態的區別
BLOCKED是指線程正在等待獲取鎖；WAITING是指線程正在等待其他線程發來的通知（notify），收到通知後，可能會順序向後執行（RUNNABLE），也可能會再次獲取鎖，進而被阻塞住（BLOCKED）
Ⅹ Java線程狀態中BLOCKED和WAITING有什麼區別
locked表示鎖住，cpu由當前線程使用；
waiting表示等待，cpu讓其他線程先執行,當前線程不使用cpu（不進行計算的意思）