Java 多线程，死锁

如果要做更精细的控制,建议你去看一下java.util.concurrent.ExecutorCompletionService类.
这个类的api的两个例子就足够经典了.

像这种多线程之间存在共享资源的情况，一定要在操作共享资源的代码上加同步锁。就像你这代码里面的打印语句和--tickets语句就要加上同步锁，不能让它们在多个线程之间分开执行，否则会出错。因为线程的调度由操作系统决定，所以线程的执行顺序以及切换时机都不是确定的。

比如synchronized(this)增加封锁控制。可以用synchronized(this){
--tickets;
}控制并发

 

如何实现线程的第三种执行方式，即单次交替式执行？

我们有时需要人为的控制线程的执行方式，如：A线程先执行一次，然后B线程再执行一次，然后A线程再执行一次，即单次交替式执行。这需要借助开关变量、门锁和，wait(),notify()方法实现。

(1)首先wait（）和notify()方法只能由synchronized中的锁来调用，任何对象调用都是无效的，因而2个方法只能写在synchronized的语句块中。这是2者的共同点。

（2）wait()和notify()的作用是什么，它们到底执行了什么？

wait()：停止执行当前的t1线程，并释放当前的锁，或者说把synchronized大门后的锁解除。剥夺该线程反锁的资格。这样t2线程才有机会执行，否则程序有可能卡住。

notify()：通知另外一个持相同锁的t2线程，不用无限期的等下去，您已经获得了反锁的资格，可以准备抢锁了，要注意，并不是说notify（）一执行，刚才被等待的线程就会立即执行。必须等t2线程执行完notify()后面的语句，直到走出synchronized(){}语句块。释放了锁，t1才可以去抢锁，但同时，t2也依然可以抢锁，所以此时要通过一个开关变量和wait()要求t2释放抢到的锁。以保证轮到t1执行。这是我在notify()语句后加上sleep()语句测试的。

 

(3) 为什么这些操作线程的方法要定义Object类中呢？

因为这些方法在操作同步中线程时，都必须要标识它们所操作线程只有的锁，

只有同一个锁上的被等待线程，可以被同一个锁上notify唤醒。

不可以对不同锁中的线程进行唤醒。

也就是说，等待和唤醒必须是同一个锁。

而锁可以是任意对象，所以可以被任意对象调用的方法定义Object类中。

如何避免Java线程死锁 ?

多线程是困难的，在开始编程之前详细设计系统能够帮助你避免难以发现Java线程死锁的问题。
    Volatile 变量，volatile 关键字是 Java 语言为优化编译器设计的。

无法访问的Java线程死锁有时候虽然获取对象锁没有问题，线程依然有可能进入阻塞状态。在 Java 编程中IO就是这类问题最好的例子。当线程因为对象内的IO调用而阻塞时，此对象应当仍能被其他线程访问。该对象通常有责任取消这个阻塞的IO操作。造成阻塞调用的线程常常会令同步任务失败。如果该对象的其他方法也是同步的，当线程被阻塞时，此对象也就相当于被冷冻住了。
    其他的线程由于不能获得对象的Java线程死锁，就不能给此对象发消息(例如，取消 IO 操作)。必须确保不在同步代码中包含那些阻塞调用，或确认在一个用同步阻塞代码的对象中存在非同步方法。尽管这种方法需要花费一些注意力来保证结果代码安全运行，但它允许在拥有对象的线程发生阻塞后，该对象仍能够响应其他线程。

2、死锁形成原因解读

a首先锁了自己，b锁了自己，

a去拿b的锁，发现b已经锁定了，则等待b的锁释放

b去拿a的锁，发现a已经锁定，则等待a释放。

就这样a等b,b也等a，造成了死锁的问题。

3、死锁的必要条件

两个或两个以上的线程在活动

某个线程拿到了一个锁以后，还想去拿第二个锁，即锁的嵌套

4、预防死锁的编程规范和方法。

@1、如果某个对象拿到了自己的锁，如果想要去拿另外对象的锁，一定要先释放自己的锁。任何锁嵌套都是不安全的

@2、加锁的代码块，其中尽量不要去调用另外的方法。因为很难在子方法中施放锁。如果需要调用到其他的方法，需确定该方法以及其子分支肯定不会申请本锁以外的锁。

@3、遇到锁中必须调用其他锁的情况，必须确定下个锁对象中不会再回调。所有锁调用都是拓扑序的。

@4、在生产者--消费者模型中，使用仓库的概念使得生产者与消费者脱离，即生产者不会需要去拿消费者的锁，消费者也不会去需要拿生产者的锁。他们只需要去拿仓库的锁。

 

二、jconsole检查死锁问题
配置
l
JRE
打开：java\jdk1.5.0\jre\lib\management目录，修改management.properties文件
无SSL加密：（去掉161行注释）
#For RMI monitoring without SSL use the following line
com.sun.management.jmxremote.ssl=false
无用户密码验证：（去掉203行注释）
# For RMI monitoring without any checking use the following line
com.sun.management.jmxremote.authenticate=false

本地调试配置eclipse
在jvm启动参数中,配置
-Dcom.sun.management.jmxremote.port=9393
同时也要设置运行的JRE为1.5以上

l
运行jconsole：

打开Windows命令行，如果本机上已经装有JDK1.5，并且路径配置正确，直接键入：jconsole
本地系统可以直接连接，远程需要自己输入IP连接

  4. wait（） 和 notify（） 方法：两个方法配套使用，wait（）使得线程进入阻塞状态，它有两种形式，一种允许指定以毫秒为单位的一段时间作为参数，另一种没有参数，前者当对应的 notify（）被调用或者超出指定时间时线程重新进入可执行状态，后者则必须对应的 notify（） 被调用。

  2和4区别的核心在于，前面叙述的所有方法，阻塞时都不会释放占用的锁（如果占用了的话），而这一对方法则相反。上述的核心区别导致了一系列的细节上的区别。

其次，前面叙述的所有方法都可在任何位置调用，但是这一对方法却必须在 synchronized 方法或块中调用，理由也很简单，只有在synchronized 方法或块中当前线程才占有锁，才有锁可以释放。同样的道理，调用这一对方法的对象上的锁必须为当前线程所拥有，这样才有锁可以释放。因此，这一对方法调用必须放置在这样的 synchronized 方法或块中，该方法或块的上锁对象就是调用这一对方法的对象。若不满足这一条件，则程序虽然仍能编译，但在运行时会出现 IllegalMonitorStateException 异常。

    wait（） 和 notify（） 方法的上述特性决定了它们经常和synchronized 方法或块一起使用，将它们和操作系统的进程间通信机制作一个比较就会发现它们的相似性：synchronized方法或块提供了类似于操作系统原语的功能，它们的结合用于解决各种复杂的线程间通信问题。

    关于 wait（） 和 notify（） 方法最后再说明两点：

    第一：调用 notify（） 方法导致解除阻塞的线程是从因调用该对象的 wait（） 方法而阻塞的线程中随机选取的，我们无法预料哪一个线程将会被选择，所以编程时要特别小心，避免因这种不确定性而产生问题。

    第二：除了 notify（），还有一个方法 notifyAll（） 也可起到类似作用，唯一的区别在于，调用 notifyAll（）方法将把因调用该对象的wait（）方法而阻塞的所有线程一次性全部解除阻塞。当然，只有获得锁的那一个线程才能进入可执行状态。

    谈到阻塞，就不能不谈一谈死锁，略一分析就能发现，suspend（） 方法和不指定超时期限的 wait（） 方法的调用都可能产生死锁。遗憾的是，Java 并不在语言级别上支持死锁的避免，我们在编程中必须小心地避免死锁。

    以上我们对 Java 中实现线程阻塞的各种方法作了一番分析，我们重点分析了 wait（） 和 notify（）方法，因为它们的功能最强大，使用也最灵活，但是这也导致了它们的效率较低，较容易出错。实际使用中我们应该灵活使用各种方法，以便更好地达到我们的目的。

 

2.多线程问题：

如何包装一个线程(Decorate 装饰器模式)?

 

 

3.

线程A对线程B无限期等待造成未能重新分发消息（包括界面重绘WM_PAINT, 定时WM_TIMER以及硬件输入和系统消息，就里特指WM_PAINT消息），造成线程B的阻塞，线程B的阻塞又造成线程A的进一步等待造成线程A的阻塞，这就导致了死锁。

 

解决方法是：设置WaitForSingleObject的等待时间为一定值，如500毫秒，这样，线程A如若等不到线程B的结束，也会返回，并分发消息，使得线程B的执行得以正常继续，从而也就保证了线程A和线程B之间的正常同步！