线程A执行wait进入休眠状态，再次被唤醒后，从断点处继续执行还是从头开始？为什么要发出这个异常？还要使用try{}catch(){}语句捕获异常？

第一：应该从断点处继续执行   第二：为什么会抛出异常；IllegalMonitorStateException - 如果当前线程不是此对象监视器的所有者。  InterruptedException - 如果在当前线程等待通知之前或者正在等待通知时，任何线程中断了当前线程。在抛出此异常时，当前线程的中断状态 被清除。  第三：可以try也可以throw

楼主你好，如果问题已解决请将帖子状态修改为提问结束，
如果未解决请继续追问，谢谢合作
修改方法请看解释帖：http://bbs.itheima.com/thread-89313-1-1.html

从断点处开始执行，不然使用wait（）每次都要从头执行，就不叫休眠了。使用多线程时特别好主意，线程的同步问题，不然得不尝试，

唤醒后从断点处开始执行，不是发生异常，而是为了避免发生异常的处理机制，这就需要一些多线程的解释了。

在
java
多线程程序中，所有线程都不允许抛出未捕获的
checked
exception
，也就是
说各个线程需要自己把自己的
checked
exception
处理掉。这一点是通过
java.lang.Runna
ble.run()
方法声明
(
因为此方法声明上没有
throw
exception
部分
)
进行了约束。但是线程依
然有可能抛出
unchecked
exception
，当此类异常跑抛出时，线程就会终结，而对于主线程
和其他线程完全不受影响，且完全感知不到某个线程抛出的异常
(
也是说完全无法
catch
到
这个异常
)
。
JVM
的这种设计源自于这样一种理念：
“
线程是独立执行的代码片断，
线程的问
题应该由线程自己来解决，而不要委托到外部。
”
基于这样的设计理念，在
Java
中，线程方
法的异常（无论是
checked
还是
unchecked
exception
），都应该在线程代码边界之内（
r
un
方法内）进行
try
catch
并处理掉
.




但如果线程确实没有自己
try
catch
某个
unchecked
exception
，而我们又想在线程代
码边界之外（
run
方法之外）来捕获和处理这个异常的话，
java
为我们提供了一种线程内发
生异常时能够在线程代码边界之外处理异常的回调机制，
即
Thread
对象提供的
setUncaug
htExceptionHandler(Thread.UncaughtExceptionHandler
eh)
方法。


通过该方法给某个
thread
设置一个
UncaughtExceptionHandler
，
可以确保在该线程出现异
常时能通过回调
UncaughtExceptionHandler
接口的
public
void
uncaughtException(Threa
d
t,
Throwable
e)
方法来处理异常，
这样的好处或者说目的是可以在线程代码边界之外
（
T
hread
的
run()
方法之外），有一个地方能处理未捕获异常。但是要特别明确的是：虽然是
在回调方法中处理异常，但这个回调方法在执行时依然还在抛出异常的这个线程中！





比之上述方法，
还有一种编程上的处理方式可以借鉴，
即，
有时候主线程的调用方可能
只是想知道子线程执行过程中发生过哪些异常，
而不一定会处理或是立即处理，
那么发起子
线程的方法可以把子线程抛出的异常实例收集起来作为一个
Exception
的
List
返回给调用
方，由调用方来根据异常情况决定如何应对。不过要特别注意的是，此时子线程早以终结。

在java多线程程序中，所有线程都不允许抛出未捕获的checked exception，也就是说各个线程需要自己把自己的checked exception处理掉。这一点是通过java.lang.Runnable.run()方法声明(因为此方法声明上没有throw exception部分)进行了约束。但是线程依然有可能抛出unchecked exception，当此类异常跑抛出时，线程就会终结，而对于主线程和其他线程完全不受影响，且完全感知不到某个线程抛出的异常(也是说完全无法catch到这个异常)。JVM的这种设计源自于这样一种理念：“线程是独立执行的代码片断，线程的问题应该由线程自己来解决，而不要委托到外部。”基于这样的设计理念，在Java中，线程方法的异常（无论是checked还是unchecked exception），都应该在线程代码边界之内（run方法内）进行try catch并处理掉.
    但如果线程确实没有自己try catch某个unchecked exception，而我们又想在线程代码边界之外（run方法之外）来捕获和处理这个异常的话，java为我们提供了一种线程内发生异常时能够在线程代码边界之外处理异常的回调机制，即Thread对象提供的setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)方法。  
通过该方法给某个thread设置一个UncaughtExceptionHandler，可以确保在该线程出现异常时能通过回调UncaughtExceptionHandler接口的public void uncaughtException(Thread t, Throwable e) 方法来处理异常，这样的好处或者说目的是可以在线程代码边界之外（Thread的run()方法之外），有一个地方能处理未捕获异常。但是要特别明确的是：虽然是在回调方法中处理异常，但这个回调方法在执行时依然还在抛出异常的这个线程中！     比之上述方法，还有一种编程上的处理方式可以借鉴，即，有时候主线程的调用方可能只是想知道子线程执行过程中发生过哪些异常，而不一定会处理或是立即处理，那么发起子线程的方法可以把子线程抛出的异常实例收集起来作为一个Exception的List返回给调用方，由调用方来根据异常情况决定如何应对。不过要特别注意的是，此时子线程早以终结

调用 wait ()/notify ()/notifyAll ()中的任何一个方法时，如果当前线程没有获得该对象的锁，那么就会抛出 IllegalMonitorStateException 的异常
也就是说程序在没有执行对象的任何同步块或者同步方法时，仍然尝试调用 wait ()/notify ()/notifyAll ()时。由于该异常是 RuntimeExcpetion 的子类，
所以该异常不一定要捕获(尽管你可以捕获只要你愿意
作为 RuntimeException，此类异常不会在 wait (),notify (),notifyAll ()的方法签名提及

最好配有代码示例，“这个异常”指的是哪个异常等等。