Ⅰ 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（不进行计算的意思）