本文目录一览：
JAVA死锁
主线程保持着A对象的锁意思就是主线程正在处理A对象，其他线程不能处理，要等待主线程结束之后其他线程才能处理A对象。
同理副线程正在处理B对象，A不能处理，所以主线程结束不了，一直在等待。
两个线程都运行不下去了就叫做死锁，程序崩溃。
加锁的意思就是某线程正在处理某对象，其他线程不能处理。
手打不容易，明白不明白都给分吧- -、
北大青鸟java培训：如何避免死锁？
什么是死锁，如何避免死锁？线程A需要资源X，而线程B需要资源Y，而双方都掌握有对方所要的资源，这种情况称为死锁（deadlock），或死亡拥抱（thedeadlyembrace）。
在并发程序设计中，江苏电脑培训建议死锁(deadlock)是一种十分常见的逻辑错误。
通过采用正确的编程方式，死锁的发生不难避免。
死锁的四个必要条件在计算机专业的教材中，通常都会介绍死锁的四个必要条件。
这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。
我们来复习一下，这四个条件是：互斥（Mutualexclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；持有（Holdandwait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；不可剥夺（Nopreemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；环形等待（Circularwait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。
解除死锁的必要条件不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。
通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁操作均作为事务对待，一旦开始上锁，即确保全部操作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。
这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。
消除第四项条件是比较容易且代价较低的办法。
具体来说这种方法约定：上锁的顺序必须一致。
具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。
无论已持有任何锁，该执行绪所有的上锁操作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。
请注意，放锁的顺序并不会导致死锁。
也就是说，尽管按照锁A,锁B,放A,放B这样的顺序来进行锁操作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。
解决方法：1使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务（细化处理逻辑，执行一段逻辑后便回滚或者提交，然后再执行其它逻辑，直到事物执行完毕提交）；2设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂； 3优化程序，检查并避免死锁现象出现； 4对所有的脚本和SP都要仔细测试，在正是版本之前。
5所有的SP都要有错误处理（通过@error） 6一般不要修改SQLSERVER事务的默认级别。
不推荐强行加锁另外参考的解决方法：按同一顺序访问对象如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。
例如，如果两个并发事务获得Supplier表上的锁，然后获得Part表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在Supplier表上。
第一个事务提交或回滚后，第二个事务继续进行。
不发生死锁。
将存储过程用于所有的数据修改可以标准化访问对象的顺序。
北大青鸟java培训：在Java程序中处理数据库超时与死锁？
每个使用关系型数据库的程序都可能遇到数据死锁或不可用的情况，而这些情况需要在代码中编程来解决;本文主要介绍与数据库事务死锁等情况相关的重试逻辑概念，此外，还会探讨如何避免死锁等问题，文章以DB2(版本9)与为例进行讲解。
什么是数据库锁定与死锁锁定(Locking)发生在当一个事务获得对某一资源的“锁”时，这时，其他的事务就不能更改这个资源了，这种机制的存在是为了保证数据一致性;在设计与数据库交互的程序时，必须处理锁与资源不可用的情况。
锁定是个比较复杂的概念，仔细说起来可能又需要一大篇，所以在本文中，只把锁定看作是一个临时事件，这意味着如果一个资源被锁定，它总会在以后某个时间被释放。
而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。
如何避免锁我们可利用事务型数据库中的隔离级别机制来避免锁的创建，正确地使用隔离级别可使程序处理更多的并发事件(如允许多个用户访问数据)，还能预防像丢失修改(LostUpdate)、读“脏”数据(DirtyRead)、不可重复读(NonrepeatableRead)及“虚”(Phantom)等问题。
隔离级别问题现象丢失修改读“脏”数据不可重复读“虚”可重复读取NoNoNoNo读取稳定性NoNoNoYes光标稳定性NoNoYesYes未提交的读NoYesYesYes表1：DB2的隔离级别与其对应的问题现象在只读模式中，就可以防止锁定发生，而不用那些未提交只读隔离级别的含糊语句。
浙江电脑培训发现一条SQL语句当使用了下列命令之一时，就应该考虑只读模式了
Java Swing多线程死锁问题解析
在基于Java Swing进行图形界面开发的时候 经常遇到的就是Swing多线程问题 我们可以想想一下 如果需要在一个图形界面上显示很多数据 这些数据是经过长时间 复杂的查询和运算得到的 如果在图形界面的同一个线程中进行查询和运算工作则会导致一段时间界面处于死机状态 这会给用户带来不良的互动感受 为了解决这个问题 一般会单独启动一个线程进行运算和查询工作 并随时更新图形界面 这时候 另一个问题就出现了 可能不仅没有解决原来偶尔死机问题 还可能导致程序彻底死掉 幸运的是在JDK中暗藏了一个中断程序的快捷键 就是CTRL+BREAK 这个快捷键Sun并没有在文档中公布 如果在命令行模式下启动Java程序 然后按CTRL+BREAK键 会得到堆栈的跟踪信息 从这些跟踪信息中就可以知道具体引发死机的位置了
当一个程序产生死锁的时候 你一定会希望尽快找到原因并且解决它 这时候 你一般的精力会用在查找引发死锁的位置 另一半的精力会用于对堆栈进行跟踪一确定引发死锁的原因 但是在Java Swing程序中 你的所有努力可能都是没有价值的 这是因为Java对Swing的多线程编程有一个特殊要求 就是在Swing里 只能在与Swing相同的线程里对GUI元件进行修改
也就是说 如果你要执行类似于jLabel setText( blabla )代码 必须在Swing线程中 而不允许在其他线程当中 如果必须在其他线程中修改元件 可以使用类似一下方式解决
SwingUtilities invokeLater(new Runnable() {
public void run() {
jLabel setText( blabla );
}
}
invokeLater方法虽然表面有时间延迟执行含义 但是实际上几乎没有任何影响 可能在几毫秒之内就会被执行 另外还有一个invokeAndWait方法 除非特殊需要 否则几乎是不用的
在不使用invokeLater的情况下 导致刷新问题是可以理解的 但是导致死锁就优点令人匪夷所思了 幸运的是 不是任何时候都需要调用改方法 这是因为大多数情况下 我们都是在与Swing同一个线程里进行界面更新 例如监听按钮点击事件的ActionListener actionPerformed方法就是运行在与Swing相同的线程中的 但是如果在回调类中引用了另一个类 并且是不属于AWT/Swing的 那么结果就很难确定了 所以说使用invokeLater应该是最安全的
需要注意的是 在invokeLater做的任何事情 都会导致Swing线程窗口绘制工作暂停下来 等候invokeLater工作结束 所以不要在invokeLater进行耗时操作 尽量只执行那些界面绘制相关的工作 可以通过代码重构 将那些与界面更新相关的代码集中起来统一处理
lishixinzhi/Article/program/Java/gj/201311/27498
