A. 如何避免java多线程中的死锁
死锁产生的必要条件
产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。
互斥条件：进程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某 资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。
不剥夺条件：进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能 由获得该资源的进程自己来释放（只能是主动释放)。
请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源 已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。
循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被 链中下一个进程所请求。即存在一个处于等待状态的进程集合{Pl, P2, ..., pn}，其中Pi等 待的资源被P(i+1)占有（i=0, 1, ..., n-1)，Pn等待的资源被P0占有
B. java多线程死锁问题
public class Test520 {//测试类
public static void main(String[] args) {
Test1 t1=new Test1();//构造线程1
Test2 t2=new Test2();//构造线程2
t1.start();//启动线程1
t2.start();//启动线程2
}
}
class Test1 extends Thread{//线程类1
public void run() {//线程类1的run方法
synchronized (A.class) {//线程类1获取A类的锁
new A().a();//构建A类调用a方法，线程可以执行到这里
synchronized (B.class) {//线程1请求获取B类的锁，看后面的代码我们知道B类的锁在线程2中，形成死锁
new B().b();//构造B类，调用b方法，这语句无法执行，因线程1始终无法获得已被线程2获得的B类锁
}
}
}
}
class Test2 extends Thread{//线程类2
public void run() {//线程类2的run方法
synchronized (B.class) {//线程2获取了B类的锁，因此线程1无法在调用a方法后获取B类锁执行后面的语句
new A().a();//构造A类对象调用a方法，此语句可以执行
synchronized (A.class) {//线程2请求A类锁，A类锁此时被线程1持有
new B().b();//如果线程2能够获取A类锁，就能执行这一步，测试知道，无法执行到这句
}
}
}
}
class A{//测试类
public void a() {
System.out.println("a");
}
}
class B{//测试类
public void b() {
System.out.println("b");
}
}
C. 怎么处理JAVA多线程死锁问题
有两种实现方法，分别是继承Thread类与实现Runnable 接口
用synchronized关键字修饰同步方法
反对使用stop()，是因为它不安全。它会解除由线程获取的所有锁定，而且如果对象处于一种不连贯状态，那么
其他线程能在那种状态下检查和修改它们。结果很难检查出真正的问题所在。suspend()方法容易发生死锁。调用
suspend()的时候，目标线程会停下来，但却仍然持有在这之前获得的锁定。此时，其他任何线程都不能访问锁定
的资源，除非被"挂起"的线程恢复运行。对任何线程来说，如果它们想恢复目标线程，同时又试图使用任何一个
锁定的资源，就会造成死锁。所以不应该使用suspend()，而应在自己的Thread类中置入一个标志，指出线程应该
活动还是挂起。若标志指出线程应该挂起，便用wait()命其进入等待状态。若标志指出线程应当恢复，则用一个
notify()重新启动线程。
D. 求解java多线程的死锁
你这是同步锁，锁的是A对象。有线程跟你一样用 A对象当锁的时候 ，只会有一条线程 来执行 B。其他线程都得等待。
1.A区域究竟什么对象可以作为锁?
对象，类对象。类对象 全局只有一个 比如 A.class ，当有人用到 这个类对象的时候 就会将其锁住。不让其他线程进入。
2.是不是我在一个线程中将A这个对象作为锁,在另一个线程中对A这个对象进行操作,就会发生死锁?
死锁的根本原因1）是多个线程涉及到多个锁，这些锁存在着交叉，所以可能会导致了一个锁依赖的闭环；2）默认的锁申请操作是阻塞的。所以要避免死锁，就要在一遇到多个对象锁交叉的情况，就要仔细审查这几个对象的类中的所有方法，是否存在着导致锁依赖的环路的可能性。要采取各种方法来杜绝这种可能性。
你这样 锁不到的。举个例子 死锁 就是 x线程 锁住了 A对象 然后 调用B对象的方法，y线程 锁住了B对象调用A对象的方法，两边 都在互相尝试获取对方的锁，但是拿不到。因为 x锁住了A对象。y锁住了B对象。他们互相拿不到 就叫死锁。这只是个例子还有很多。
3不是说任何对象都可以作为一把锁吗?那么每一个锁我使用一个独立的成员对象作为锁,不就是可以很容易避开死锁吗？为什么说死锁很容易发生?
你每个锁用一个独立的成员对象作为锁，没问题，只要没有存在交叉。上面那个例子一样。
避免死锁是一件困难的事，遵循以下原则有助于规避死锁：
1、只在必要的最短时间内持有锁，考虑使用同步语句块代替整个同步方法；
2、尽量编写不在同一时刻需要持有多个锁的代码，如果不可避免，则确保线程持有第二个锁的时间尽量短暂；
3、创建和使用一个大锁来代替若干小锁，并把这个锁用于互斥，而不是用作单个对象的对象级别锁；
E. 如何解决多线程造成的数据库死锁
多线程是很容易造成死锁，一般情况下死锁都是因为并发操作引起的。我不懂JAVA,但死锁这个问题每种开发工具和数据库都会碰到.解决办法是：
1、程序方面优化算法（如有序资源分配法、银行算法等），在一个程序里，能不用多线程更新同一张数据库表
尽量不要用，如果要用，其避免死锁的算法就很复杂。
2、数据库方面设置等待超时时间
3、发生死锁后直接KILL掉数据库进程
F. 什么是java多线程中的死锁
两个或者多个线程之间相互等待，导致线程都无法执行，叫做线程死锁。
产生死锁的条件：
1.有至少一个资源不能共享
2.至少有一个任务必须持有一个资源并且等待获取另一个被别的任务持有的资源
3.资源不能任务抢占
4.必须有循环等待
G. 如何理解Java中的死锁
死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不可能正常终止。
导致死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的作用是，确保在某个时刻只有一个线程被允许执行特定的代码块，因此，被允许执行的线程首先必须拥有对变量或对象的排他性的访问权。当线程访问对象时，线程会给对象加锁，而这个锁导致其它也想访问同一对象的线程被阻塞，直至第一个线程释放它加在对象上的锁。
由于这个原因，在使用“synchronized”关键词时，很容易出现两个线程互相等待对方做出某个动作的情形。代码一是一个导致死锁的简单例子。
//代码一
class Deadlocker {
int field_1;
private Object lock_1 = new int[1];
int field_2;
private Object lock_2 = new int[1];
public void method1(int value) {
“synchronized” (lock_1) {
“synchronized” (lock_2) {
field_1 = 0; field_2 = 0;
}
}
}
public void method2(int value) {
“synchronized” (lock_2) {
“synchronized” (lock_1) {
field_1 = 0; field_2 = 0;
}
}
}
}
参考代码一，考虑下面的过程：
◆ 一个线程（ThreadA）调用method1()。
◆ ThreadA在lock_1上同步，但允许被抢先执行。
◆ 另一个线程（ThreadB）开始执行。
◆ ThreadB调用method2()。
◆ ThreadB获得lock_2，继续执行，企图获得lock_1。但ThreadB不能获得lock_1，因为ThreadA占有lock_1。
◆ 现在，ThreadB阻塞，因为它在等待ThreadA释放lock_1。
◆ 现在轮到ThreadA继续执行。ThreadA试图获得lock_2，但不能成功，因为lock_2已经被ThreadB占有了。
◆ ThreadA和ThreadB都被阻塞，程序死锁。
当然，大多数的死锁不会这么显而易见，需要仔细分析代码才能看出，对于规模较大的多线程程序来说尤其如此。好的线程分析工具，例如JProbe Threadalyzer能够分析死锁并指出产生问题的代码位置。
隐性死锁
隐性死锁由于不规范的编程方式引起，但不一定每次测试运行时都会出现程序死锁的情形。由于这个原因，一些隐性死锁可能要到应用正式发布之后才会被发现，因此它的危害性比普通死锁更大。下面介绍两种导致隐性死锁的情况：加锁次序和占有并等待。
加锁次序
当多个并发的线程分别试图同时占有两个锁时，会出现加锁次序冲突的情形。如果一个线程占有了另一个线程必需的锁，就有可能出现死锁。考虑下面的情形，ThreadA和ThreadB两个线程分别需要同时拥有lock_1、lock_2两个锁，加锁过程可能如下：
◆ ThreadA获得lock_1；
◆ ThreadA被抢占，VM调度程序转到ThreadB；
◆ ThreadB获得lock_2；
◆ ThreadB被抢占，VM调度程序转到ThreadA；
◆ ThreadA试图获得lock_2，但lock_2被ThreadB占有，所以ThreadA阻塞；
◆ 调度程序转到ThreadB；
◆ ThreadB试图获得lock_1，但lock_1被ThreadA占有，所以ThreadB阻塞；
◆ ThreadA和ThreadB死锁。
必须指出的是，在代码丝毫不做变动的情况下，有些时候上述死锁过程不会出现，VM调度程序可能让其中一个线程同时获得lock_1和lock_2两个锁，即线程获取两个锁的过程没有被中断。在这种情形下，常规的死锁检测很难确定错误所在。
占有并等待
如果一个线程获得了一个锁之后还要等待来自另一个线程的通知，可能出现另一种隐性死锁，考虑代码二。
//代码二
public class queue {
static java.lang.Object queueLock_;
Procer procer_;
Consumer consumer_;
public class Procer {
void proce() {
while (!done) {
“synchronized” (queueLock_) {
proceItemAndAddItToQueue();
“synchronized” (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
“synchronized” (queueLock_) {
“synchronized” (consumer_) {
consumer_.wait();
}
();
}
}
}
}
}
}
在代码二中，Procer向队列加入一项新的内容后通知Consumer，以便它处理新的内容。问题在于，Consumer可能保持加在队列上的锁，阻止Procer访问队列，甚至在Consumer等待Procer的通知时也会继续保持锁。这样，由于Procer不能向队列添加新的内容，而Consumer却在等待Procer加入新内容的通知，结果就导致了死锁。
在等待时占有的锁是一种隐性的死锁，这是因为事情可能按照比较理想的情况发展—Procer线程不需要被Consumer占据的锁。尽管如此，除非有绝对可靠的理由肯定Procer线程永远不需要该锁，否则这种编程方式仍是不安全的。有时“占有并等待”还可能引发一连串的线程等待，例如，线程A占有线程B需要的锁并等待，而线程B又占有线程C需要的锁并等待等。
要改正代码二的错误，只需修改Consumer类，把wait()移出“synchronized”()即可。
H. java多线程中的死锁，活锁，饥饿，无锁都是什么鬼
死锁发生在当一些进程请求其它进程占有的资源而被阻塞时。
另外一方面，活锁不会被阻塞，而是不停检测一个永远不可能为真的条件。除去进程本身持有的资源外，活锁状态的进程会持续耗费宝贵的CPU时间。
最后，进程会处于饥饿状态是因为持续地有其它优先级更高的进程请求相同的资源。不像死锁或者活锁，饥饿能够被解开。例如，当其它高优先级的进程都终止时并且没有更高优先级的进程到达。
I. Java 多线程中 什么是死锁有什么作用
所谓死锁:
是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。