blocks|key|1540772|text|我脑海中的一些小贴士|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1540773|1540774|不使用多线程(就像Swing一样，例如，通过强制在EDT中完成所有操作)|unordered-list-item|1540775|不会同时持有多个锁。如果这样做，请始终以相同的顺序获取锁|1540776|不要在持有锁的同时执行外部代码|1540777|1540778|使用可中断的锁|1540779|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|E|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

Some quick tips out of my head

<ul>
<li>don't use multiple threads (like Swing does, for example, by mandating that everything is done in the EDT)</li>
<li>don't hold several locks at once. If you do, always acquire the locks in the same order</li>
<li>don't execute foreign code while holding a lock</li>
<li>use interruptible locks</li>
</ul>

blocks|key|452495|text|封装，封装，封装！使用锁可能犯的最危险的错误是将锁暴露给世界(使其公开)。如果你这样做，不知道会发生什么，因为任何人都可以在对象不知道的情况下获得锁(这也是为什么你不应该锁定this)。如果你保持你的锁是私有的，那么你就拥有了完全的控制权，这使得它更易于管理。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|452496|entityMap^0|0|9|2F|4|0^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|D]]|E|@]|F|$]]|$1|G|3|-4|5|6|7|N|8|@]|E|@]|F|$]]]|H|$]]

Encapsulate, encapsulate, encapsulate! Probably the most dangerous mistake you can make with locks is exposing your lock to the world (making it public). There is no telling what can happen if you do this as anyone would be able to acquire the lock without the object knowing (this is also why you shouldn't lock <code>this</code>). If you keep your lock private then you have complete control and this makes it more manageable.

blocks|key|3662954|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3662955|通过使用无锁数据结构来避免锁(例如，使用ConcurrentLinkedQueue而不是同步的锁以相同的顺序获取锁，例如，为每个锁分配唯一的数值，并在获取数值较高的锁之前获取数值较低的锁)|ordered-list-item|offset|length|style|CODE|3662956|在超时时间后释放锁(从技术上讲，这并不能防止死锁，只是有助于在发生死锁后解决它们)|3662957|3662958|entityMap^0|0|K|L|0|0|0^^$0|@$1|2|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|N|7|@$D|O|E|P|F|G]]|8|@]|9|$]]|$1|H|3|I|4|C|6|Q|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|R|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|S|7|@]|8|@]|9|$]]]|L|$]]

<ol>
<li>Avoid locks by using lock-free data structures (e.g. use a <code>ConcurrentLinkedQueue</code> instead of a synchronized <code>ArrayList</code>)</li>
<li>Always acquire the locks in the same order, e.g. assign a unique numerical value to each lock and acquire the locks with lower numerical value before acquiring the locks with higher numerical value</li>
<li>Release your locks after a timeout period (technically this doesn't prevent deadlocks, it just helps to resolve them after they've occurred)</li>
</ol>

blocks|key|453675|text|阅读并理解Java:并发性与实践。这不是关于避免死锁的“提示”。我永远不会雇佣一个知道一些技巧来避免死锁并且经常避免死锁的开发人员。这是关于理解并发性的。幸运的是，有一本关于这个主题的全面的中级书籍，所以去读一读吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|453676|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Read and understand Java: Concurrency and Practice. This isn't about "tips" to avoid deadlock. I would never hire a developer who knew a few tips to avoid deadlock and often avoided deadlock. It's about understanding concurrency. Fortunately there is a comprehensive intermediate-level book on the topic, so go read it.

blocks|key|1594636|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1594637|不使用锁。|ordered-list-item|1594638|如果需要，请将您的锁保留在本地。全局锁可能真的很棘手。当你持有锁时，|1594639|尽可能少做。|1594640|使用stripes只锁定你的数据段|offset|length|1594641|更喜欢不可变的类型。很多时候，这意味着复制数据而不是共享数据。|1594642|使用比较和设置(CAS)机制，例如参见AtomicReference。|1594643|1594644|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/Striped.html|1|http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicReference.html^0|0|0|0|0|2|7|0|0|0|J|F|1|0|0^^$0|@$1|2|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|11|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|12|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|13|7|@]|8|@]|9|$]]|$1|H|3|I|4|C|6|14|7|@]|8|@$J|15|K|16|1|17]]|9|$]]|$1|L|3|M|4|C|6|18|7|@]|8|@]|9|$]]|$1|N|3|O|4|C|6|19|7|@]|8|@$J|1A|K|1B|1|1C]]|9|$]]|$1|P|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]]|R|$S|$4|T|U|V|9|$W|X]]|Y|$4|T|U|V|9|$W|Z]]]]

<ol>
<li>Don't use locks.</li>
<li>If you must, keep your locks local. Global locks can be really tricky.</li>
<li>Do as little as possible when you hold the lock.</li>
<li>Use <a href="http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/Striped.html">stripes</a> to only lock segments of your data</li>
<li>Prefer Immutable types. Many times this means copying data instead of sharing data.</li>
<li>Use compare and set (CAS) mechanics instead, See <a href="http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicReference.html">AtomicReference</a> for example.</li>
</ol>

blocks|key|3662895|text|当涉及到防止死锁时，几乎只有一个很大的规则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3662896|3662897|如果你需要在你的代码中有多个锁，确保每个人总是以相同的顺序获得它们。|blockquote|3662898|3662899|3662900|不过，让你的代码远离锁应该一直是你的目标。您可以尝试通过使用不可变或线程本地对象和无锁数据结构来摆脱它们。|3662901|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|N|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|K|$]]

There is pretty much just one big rule when it comes to preventing deadlocks: 

<blockquote>
 If you need to have multiple locks in your code, make sure everyone always acquire them in the same order.
</blockquote>

Keeping your code free from locks should pretty much always be your goal though. You can try to get rid of them by using immutable or thread-local objects and lock-free data structures.

blocks|key|452478|text|给定设计选择，在队列推送/弹出中只有锁的情况下使用消息传递。这并不总是可能的，但如果是这样的话，你将会有很少的死锁。你仍然可以得到它们，但你必须非常努力:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|452479|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Given a design choice, use message-passing where there only locks are in the queue push/pop. This is not always possible but, if it is, you will have very few deadlocks. You can still get them, but you have to try really hard :)

blocks|key|1594407|text|布尔标志示例|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1594408|我喜欢这个例子。它启动两个共享布尔标志的线程：|1594409|public+class+UntilYouUpdateIt+
{
++++public+static+boolean+flag+=+true;

++++public+static+void+main(String[]+args)+throws+InterruptedException+
++++{
++++++++Thread+t1+=+new+Thread(()->
++++++++{
++++++++++++while(flag){}
++++++++++++System.out.println("end");
++++++++});
++++++++t1.start();

++++++++Thread.sleep(100);

++++++++Thread+t2+=+new+Thread(()->
++++++++{
+++++++++++flag+=+false;
+++++++++++System.out.println("changed");
++++++++});
++++++++t2.start();
++++++}
}|code-block|syntax|javascript|1594410|第一线程会循环，直到flag为false，这发生在第二个线程的第一行。程序永远不会完成，它的输出将是：|offset|length|style|CODE|1594411|changed|1594412|第二个线程死了，同时第一个线程将永远循环。|1594413|为什么会这样呢？Compiler+opmitizations。Thread1永远不会再次检查标志的值，如下所示：|1594414|1594415|循环内的操作很便宜(无事可做)|unordered-list-item|1594416|编译器知道没有其他实体可以修改标志值(因为第一个线程没有，而第二个线程已经死了)。因此，它假定始终为true.|BOLD|1594417|1594418|换句话说，在cache，中将flag值设置为true时，Thread1将始终读取该值。|1594419|1594420|有两种方法可以解决/测试这个问题：|1594421|++++Thread+t1+=+new+Thread(()->
++++{
++++++++while(flag)
++++++++{
+++++++++++System.out.print("I'm+loopinnnng");
++++++++}
++++++++System.out.println("end");
++++});|1594422|如果包含一些“繁重”的操作(int+i=1或类似的操作也不起作用)，比如System调用，优化器将更加小心，检查flag布尔值，以确定他是否在浪费资源。输出将为：|1594423|I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
(....)
changed
end|1594424|或|1594425|I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
I'm+loopinnnng
(....)
end
changed|1594426|这取决于在结束时为哪个线程分配了cpu时间。|1594427|在使用布尔变量时，避免此类死锁的正确解决方案应该包括volatile关键字。|1594428|volatile告诉编译器：当涉及到此变量时，不要尝试进行优化。|1594429|因此，添加了该关键字的相同代码：|1594430|public+class+UntilYouUpdateIt+
{
++++public+static+volatile+boolean+flag+=+true;

++++public+static+void+main(String[]+args)+throws+InterruptedException+
++++{
++++++++Thread+t1+=+new+Thread(()->
++++++++{
++++++++++++while(flag){}
++++++++++++System.out.println("end");
++++++++});
++++++++t1.start();

++++++++Thread.sleep(100);

++++++++Thread+t2+=+new+Thread(()->
++++++++{
+++++++++++flag+=+false;
+++++++++++System.out.println("changed");
++++++++});
++++++++t2.start();
++++++}
}|1594431|将输出：|1594432|changed
end|1594433|1594434|end
changed|1594435|结果是两个线程都正确完成，避免了任何死锁。|1594436|1594437|无序锁示例|1594438|这是一个基本的问题：|1594439|public+void++methodA()+
{
++//...

++synchronized(lockA)
++{
+++++//...
+
+++++synchronized(lockB)
+++++{
++++++//...
+++++}
+++}
}+


public+void+methodB()+
{
++//...

++synchronized(lockB)
++{
+++++//...
++
++++synchronized(lockA)
+++++{
++++++//...
+++++}
+++}
}|1594440|如果被许多线程调用，这个方法可能会产生很大的死锁。这是因为对象以不同的顺序锁定。这是死锁最常见的原因之一，所以如果你想避免它们，请确保这些锁是按顺序获得的。|1594441|entityMap^0|0|0|0|A|4|0|0|0|8|M|0|0|0|1B|7|0|0|6|5|6|5|E|4|M|4|0|0|0|0|E|7|10|6|1K|4|0|0|0|0|0|Q|8|Q|8|0|0|8|E|I|0|0|0|0|0|0|0|3|I|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2C|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|2D|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|2E|8|@$K|2F|L|2G|M|N]]|9|@]|A|$]]|$1|O|3|P|5|F|7|2H|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|2I|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|2J|8|@$K|2K|L|2L|M|N]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|V|3|W|5|X|7|2N|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|X|7|2O|8|@$K|2P|L|2Q|M|10]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2S|8|@$K|2T|L|2U|M|10]|$K|2V|L|2W|M|N]|$K|2X|L|2Y|M|N]|$K|2Z|L|30|M|N]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|31|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|32|8|@]|9|@]|A|$]]|$1|17|3|18|5|F|7|33|8|@]|9|@]|A|$G|H]]|$1|19|3|1A|5|6|7|34|8|@$K|35|L|36|M|N]|$K|37|L|38|M|N]|$K|39|L|3A|M|N]]|9|@]|A|$]]|$1|1B|3|1C|5|F|7|3B|8|@]|9|@]|A|$G|H]]|$1|1D|3|1E|5|6|7|3C|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|F|7|3D|8|@]|9|@]|A|$G|H]]|$1|1H|3|1I|5|6|7|3E|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|3F|8|@$K|3G|L|3H|M|10]|$K|3I|L|3J|M|N]]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3K|8|@$K|3L|L|3M|M|N]|$K|3N|L|3O|M|10]]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|3P|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|F|7|3Q|8|@]|9|@]|A|$G|H]]|$1|1R|3|1S|5|6|7|3R|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|F|7|3S|8|@]|9|@]|A|$G|H]]|$1|1V|3|1E|5|6|7|3T|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|F|7|3U|8|@]|9|@]|A|$G|H]]|$1|1Y|3|1Z|5|6|7|3V|8|@$K|3W|L|3X|M|10]]|9|@]|A|$]]|$1|20|3|-4|5|6|7|3Y|8|@]|9|@]|A|$]]|$1|21|3|22|5|6|7|3Z|8|@]|9|@]|A|$]]|$1|23|3|24|5|6|7|40|8|@]|9|@]|A|$]]|$1|25|3|26|5|F|7|41|8|@]|9|@]|A|$G|H]]|$1|27|3|28|5|6|7|42|8|@]|9|@]|A|$]]|$1|29|3|-4|5|6|7|43|8|@]|9|@]|A|$]]]|2A|$]]

<h2>Boolean flag example</h2>
I love this example. It starts two threads that share a boolean flag:
<pre><code>public class UntilYouUpdateIt 
{
 public static boolean flag = true;

 public static void main(String[] args) throws InterruptedException 
 {
 Thread t1 = new Thread(()-&gt;
 {
 while(flag){}
 System.out.println(&quot;end&quot;);
 });
 t1.start();

 Thread.sleep(100);

 Thread t2 = new Thread(()-&gt;
 {
 flag = false;
 System.out.println(&quot;changed&quot;);
 });
 t2.start();
 }
}
</code></pre>
First thread will loop until <code>flag</code> is false, which happens in the first line of the 2nd thread. The program won't ever finish, and it's ouput would be:
<pre><code>changed
</code></pre>
2nd thread dies, meanwhile the 1st one will loop forever.
Why is it happenning? <code>Compiler opmitizations</code>. Thread1 will never check again flag's value, as:
<ul>
<li>the operation inside the loop is cheap (nothing to do)</li>
<li>The compiler knows there's no other entity that can modify the flag value (as the first thread doesn't, and the 2nd one is already dead). So it assumes flag will always be true.</li>
</ul>
In other words, Thread1 will always be reading the <code>flag</code> value from the <code>cache</code>, where it is set as <code>true</code>.
<hr />
Two ways to solve/test this:
<pre><code> Thread t1 = new Thread(()-&gt;
 {
 while(flag)
 {
 System.out.print(&quot;I'm loopinnnng&quot;);
 }
 System.out.println(&quot;end&quot;);
 });
</code></pre>
If some &quot;heavy&quot; operation is included (<code>int i=1</code> or similar would'nt work neither), such as a <code>System</code> call, the optimizer will be a little more careful, checking the <code>flag</code> boolean in order to know if he's not wasting resources. The output would be:
<pre><code>I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
(....)
changed
end
</code></pre>
or
<pre><code>I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
I'm loopinnnng
(....)
end
changed
</code></pre>
Depending which thread was assigned the cpu time at the end.
The correct solution to avoid these kind of deadlocks, when working with boolean variables, should be including the <code>volatile</code> keyword.
<code>volatile</code> tells the compiler: do not try to optimize when this variable is involved.
So, this same code with just that keyword added:
<pre><code>public class UntilYouUpdateIt 
{
 public static volatile boolean flag = true;

 public static void main(String[] args) throws InterruptedException 
 {
 Thread t1 = new Thread(()-&gt;
 {
 while(flag){}
 System.out.println(&quot;end&quot;);
 });
 t1.start();

 Thread.sleep(100);

 Thread t2 = new Thread(()-&gt;
 {
 flag = false;
 System.out.println(&quot;changed&quot;);
 });
 t2.start();
 }
}
</code></pre>
Will output:
<pre><code>changed
end
</code></pre>
or
<pre><code>end
changed
</code></pre>
The result is both threads finishing correctly, avoiding any deadlock.
<hr />
<h2>Unordered locks example</h2>
This one is a basic one:
<pre><code>public void methodA() 
{
 //...

 synchronized(lockA)
 {
 //...
 
 synchronized(lockB)
 {
 //...
 }
 }
} 


public void methodB() 
{
 //...

 synchronized(lockB)
 {
 //...
 
 synchronized(lockA)
 {
 //...
 }
 }
}
</code></pre>
This methods would probably create a great deadlock if called by many threads. This is because the objects are locked in different order. This is one of the most common reasons of deadlocks, so if you want to avoid them, be sure that the locks are aquired in order.

blocks|key|3663397|text|java中的死锁是两个或更多线程永远被阻塞的编程情况。Java死锁情况出现在至少两个线程和两个或更多资源的情况下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3663398|如何在Java中检测死锁|3663399|要检测Java中的死锁，我们需要查看应用程序的java线程转储，我们可以使用VisualVM分析器或使用jstack实用程序生成线程转储。|3663400|为了分析死锁，我们需要寻找状态为阻塞的线程，然后查找等待锁定的资源。每个资源都有一个唯一的ID，我们可以使用它来查找哪个线程已经持有对象上的锁。|3663401|如何在java中避免死锁|offset|length|style|BOLD|3663402|这些是我们可以用来避免大多数死锁情况的一些准则。|3663403|3663404|Avoid+deadlock+by+breaking+wait+condition：为了做到这一点，您可以在代码中进行安排，对锁的获取和释放进行排序。如果锁将以一致的顺序获取并以恰好相反的顺序释放，则不会出现一个线程持有另一个线程获取的锁的情况，反之亦然。|unordered-list-item|3663405|Avoid嵌套锁：这是死锁最常见的原因，如果你已经持有一个资源，请避免锁定另一个资源。如果你只使用一个对象锁，那么几乎不可能出现死锁的情况。只需要等待什么：|3663406|Lock你应该只在你要工作的资源上获取锁，如果我们只对它的一个字段感兴趣，那么我们应该只锁定那个特定的字段而不是完成object.|3663407|Avoid无限等待：如果两个线程正在使用+join无限期地等待对方完成，你可能会得到一个死锁。如果您的线程必须等待另一个线程完成，则最好始终使用join，使其具有您想要等待线程完成的最长时间。|3663408|3663409|entityMap^0|0|0|0|0|0|7|0|0|0|0|15|0|0|9|0|0|1T|0|0|K|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@$J|17|K|18|L|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|19|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1B|8|@$J|1C|K|1D|L|M]]|9|@]|A|$]]|$1|T|3|U|5|S|7|1E|8|@$J|1F|K|1G|L|M]]|9|@]|A|$]]|$1|V|3|W|5|S|7|1H|8|@$J|1I|K|1J|L|M]]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1K|8|@$J|1L|K|1M|L|M]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|11|$]]

Deadlock in java is a programming situation where two or more threads are blocked forever. Java deadlock situation arises with at least two threads and two or more resources.

<h2>How to Detect Deadlock in Java</h2>

To detect a deadlock in Java, we need to look at the java thread dump of the application, we can generate thread dump using VisualVM profiler or using jstack utility.

For analyzing deadlock, we need to look out for the threads with the state as BLOCKED and then the resources it’s waiting to lock. Every resource has a unique ID using which we can find which thread is already holding the lock on the object. 

<h2>How to avoid deadlock in java</h2>

These are some of the guidelines using which we can avoid most of the deadlock situations.

<ul>
<li>Avoid deadlock by breaking circular wait condition: In order to do that, you can make arrangement in the code to impose the ordering on acquisition and release of locks. If lock will be acquired in a consistent order and released in just opposite order, there would not be a situation where one thread is holding a lock which is acquired by other and vice-versa. </li>
<li>Avoid Nested Locks: This is the most common reason for deadlocks, avoid locking another resource if you already hold one. It’s almost impossible to get a deadlock situation if you are working with only one object lock. </li>
<li>Lock Only What is Required: You should acquire lock only on the resources you have to work on, if we are only interested in one of its fields, then we should lock only that specific field not complete object.</li>
<li>Avoid waiting indefinitely: You can get a deadlock if two threads are waiting for each other to finish indefinitely using thread join. If your thread has to wait for another thread to finish, it’s always best to use join with maximum time you want to wait for the thread to finish.</li>
</ul>

blocks|key|1541029|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1541030|避免嵌套锁。这是死锁最常见的原因。避免锁定另一个资源如果你已经持有one.It几乎不可能获得死锁如果你只使用一个对象锁。|ordered-list-item|1541031|只锁定需要的东西。比如锁定对象的特定字段，而不是锁定整个对象。|1541032|不会无限期地等待。|1541033|1541034|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|K|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|L|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|P|7|@]|8|@]|9|$]]]|J|$]]

<ol>
<li>Avoid nested locks. This is the most common reason for deadlock. Avoid locking another resource if you already hold one.It is almost impossible to get deadlock if you are working with only one object lock.</li>
<li>Lock only what is required. Like lock particular field of object instead of locking whole object if it serves your purpose.</li>
<li>Do not wait indefinitely.</li>
</ol>

blocks|key|3663276|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3663277|除非需要，否则不要通过多个线程共享数据。如果数据在创建/初始化后无法更改，请坚持使用最终变量。|ordered-list-item|3663278|如果您无法避免在多个线程之间共享数据，请使用粒度synchronized块或只使用synchronized代码块的代码，请确保以特定的顺序获取/释放锁。|offset|length|style|CODE|3663279|注意其他替代方案：|3663280|或AtomicXXX变量或Lock+<synchronized>G214|3663281|相关SE问题：|3663282|Avoid+synchronized(this)+in+Java?|3663283|Difference+between+volatile+and+synchronized+in+Java|3663284|Volatile+boolean+vs+AtomicBoolean|3663285|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html|1|https://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java|2|https://stackoverflow.com/questions/3519664/difference-between-volatile-and-synchronized-in-java|3|https://stackoverflow.com/questions/3786825/volatile-boolean-vs-atomicboolean^0|0|0|O|C|15|C|0|0|D|4|J|C|1|9|0|0|0|0|X|1|0|0|1G|2|0|0|X|3|0^^$0|@$1|2|3|-4|4|5|6|19|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1A|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|1B|7|@$F|1C|G|1D|H|I]|$F|1E|G|1F|H|I]]|8|@]|9|$]]|$1|J|3|K|4|C|6|1G|7|@]|8|@]|9|$]]|$1|L|3|M|4|5|6|1H|7|@$F|1I|G|1J|H|I]|$F|1K|G|1L|H|I]]|8|@$F|1M|G|1N|1|1O]]|9|$]]|$1|N|3|O|4|5|6|1P|7|@]|8|@]|9|$]]|$1|P|3|Q|4|5|6|1Q|7|@]|8|@$F|1R|G|1S|1|1T]]|9|$]]|$1|R|3|S|4|5|6|1U|7|@]|8|@$F|1V|G|1W|1|1X]]|9|$]]|$1|T|3|U|4|5|6|1Y|7|@]|8|@$F|1Z|G|20|1|21]]|9|$]]|$1|V|3|-4|4|5|6|22|7|@]|8|@]|9|$]]]|W|$X|$4|Y|Z|10|9|$11|12]]|13|$4|Y|Z|10|9|$11|14]]|15|$4|Y|Z|10|9|$11|16]]|17|$4|Y|Z|10|9|$11|18]]]]

<ol>
<li>Unless required, do not share data over multiple threads. If data can't be changed after creation/initialization, stick to final variables. </li>
<li>If you can't avoid shared data among multiple threads, use granular <code>synchronized</code> blocks or <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Lock.html" rel="nofollow noreferrer">Lock</a>s.</li>
<li>If you are using only <code>synchronized</code> code blocks, make sure that locks are acquired/released in a certain order.</li>
<li>Look out for other alternatives : volatile or <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html" rel="nofollow noreferrer">AtomicXXX</a> variables or <code>Lock</code> API </li>
</ol>

Related SE questions:

<a href="https://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java">Avoid synchronized(this) in Java?</a>

<a href="https://stackoverflow.com/questions/3519664/difference-between-volatile-and-synchronized-in-java">Difference between volatile and synchronized in Java</a>

<a href="https://stackoverflow.com/questions/3786825/volatile-boolean-vs-atomicboolean">Volatile boolean vs AtomicBoolean</a>

blocks|key|3663337|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3663338|避免嵌套锁|unordered-list-item|3663339|避免不必要的锁|3663340|使用线程联接()|3663341|3663342|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|K|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|L|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|P|7|@]|8|@]|9|$]]]|J|$]]

<ul>
<li>Avoid Nested Locks</li>
<li>Avoid Unnecessary Locks</li>
<li>Use thread join()</li>
</ul>

blocks|key|452630|text|不幸的是，存在跨多个线程的循环数据流(A->B->C->A)的数据模型。上面所说的都不适用于它。可能会有帮助的是，线程之间的数据传输方法可以使用无锁的缓冲输入，比如java并发集合。数据块本身被实现为无状态的不可变对象。GUI系统很可能使用这种方法。这样，"lockfull“等待-通知方案看起来就不需要了，但是线程并发控制仍然存在，但它隐藏在集合中，这种方式是局部的。这个问题真的很难避免。根源于数学模型假设的零延迟。但在实际系统中，每个操作都需要时间，因此会产生延迟，最终导致死锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|452631|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Unfortunately, there are data models with circular data flow (A-&gt;B-&gt;C-&gt;A) across multiple threads. All said above doesn't work for it.
From what might help, a data transfer method between threads could use a lockless buffered input like java concurrency collections. And data chunks itself are implemented as stateless immutable objects. A GUI systems highly likely use this approach. This way a &quot;lockfull&quot; wait-notify scheme appears not needed, however thread concurrency control still exists but it is hidden inside collections and this way is local.
The problem really is hardly avoidable. The roots originate from zero latency assumed by math model. But in real system every action takes time, so it creates latency and finally leads to deadlocks.

I am studying java threads and deadlocks, I understand deadlock's examples but I wonder if there are general rules to follow to prevent it.

My question is if there are rules or tips that can be applied to the source code in java to prevent deadlocks? If yes, could you explain how to implement it?

Tips to prevent deadlocks in java

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在研究java线程和死锁，我理解死锁的例子，但我想知道是否有通用的规则来防止它。我的问题是，是否有一些规则或技巧可以应用于java中的源代码，以防止死锁？如果是，你能解释一下如何实现它吗？

问在java中防止死锁的技巧
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在java中防止死锁的技巧EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在java中防止死锁的技巧
EN