使用System.out.format和System.out.println进行多线程处理

时间:2016-10-25 07:42:54

标签: java multithreading deadlock println

我在Oracle的Java Tutorial中遇到了这个example,它描述了多线程场景中的死锁。

所以在这个例子中,我在第17行和第18行进行了以下更改。

public class DeadLock {
  static class Friend {
    private final String name;

    public Friend(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    public synchronized void bow(Friend bower) {
        //My Changes
        //System.out.format("%s: %s" + " has bowed to me!%n", this.name, bower.getName()); //Line 17
         System.out.println(this.name + ": " + bower.getName() + " has bowed to me!"); //Line 18
        bower.bowBack(this);
    }

    public synchronized void bowBack(Friend bower) {
        System.out.format("%s: %s" + " has bowed back to me!%n", this.name, bower.getName());
    }
  }

  public static void main(String[] args) {
    final Friend alphonse = new Friend("Alphonse");
    final Friend gaston = new Friend("Gaston");
    new Thread(new Runnable() {
        @Override
        public void run() {
            alphonse.bow(gaston);
        }
    }).start();

    new Thread(new Runnable() {
        @Override
        public void run() {
            gaston.bow(alphonse);
        }
    }).start();
  }
}

执行这些更改后,程序成功终止,不会导致死锁并在输出后打印

Alphonse: Gaston has bowed to me!
Gaston: Alphonse has bowed back to me!
Gaston: Alphonse has bowed to me!
Alphonse: Gaston has bowed back to me!

所以我的问题是 - 为什么它会像这样? println语句是如何防止死锁的?

4 个答案:

答案 0 :(得分:5)

您使用System.out.print还是System.out.format没有区别:他们基本上做同样的事情。

如果在Gaston.bow(Alphonse)Alphonse.bow(Gaston)之间开始执行bower.bowBack(Alphonse)(反之亦然),则会发生死锁:两个线程正在等待另一个线程持有的监视器,因而发生了死锁。

这种情况不一致,因为它取决于线程的计划方式,取决于线程的调度方式,因此它取决于细微的计时问题 - Alphonse.bowbower.backBack(Alphonse)可能在执行Gaston.bow之前完成,所以看起来没有僵局。

解决此问题的经典方法是订购锁定获取,以便每次首先获取相同的锁定;这可以防止死锁的可能性:

public void bow(Friend bower) {  // Method no longer synchronized.
  int firstHash = System.identityHashCode(this);
  int secondHash = System.identityHashCode(bower);

  Object firstMonitor = firstHash < secondHash ? this : bower;
  Object secondMonitor = firstHash < secondHash ? bower : this;
  synchronized (firstMonitor) {
    synchronized (secondMonitor) {
      // Code free (*) of deadlocks, with respect to this and bower at least.
    }
  }
}

(*)它不是完全保证无死锁,因为System.identityHashCode可以为不同的对象返回相同的值;但这是不太可能的。

这是Birthday paradox的应用:如果你只有两台显示器,那么碰撞的可能性就像是10 ^ -18;但是如果你有> 77k的监视器,那么碰撞就更有可能了。

答案 1 :(得分:4)

你在这里搞混合了。

一段代码可以导致死锁的情况并不一定意味着您每次以及代码运行时都会收到死锁。

这是使多线程成为如此难题的方面之一:如果你运行一次代码,或者10次,或者100次代码,那么所有东西都可以运行&#34 ;;它仍有可能在下次失败。

换句话说:尝试将代码放在最外层的循环中,迟早(可能更早;如果你不做多少&#34;睡觉&#34;)你应该遇到死锁!

如果事情那么容易,并且很容易就能发现死锁,我们就不需要所有这些书籍和图书馆和想法来处理多线程...

答案 2 :(得分:3)

为了支持其余的答案以及一些实际的证据,我在循环中运行了你的代码,它在100次尝试中死了82次,所以你的代码肯定仍然是死锁。

答案 3 :(得分:1)

死锁完全不依赖于println函数。它是由两个线程试图互相访问并相互锁定引起的。

从格式到println的改变将在程序中引入足够的等待时间,以允许线程彼此锁定而不会发生冲突,即死锁。所以你还没有真正解决它;你刚刚添加了一些延迟,这意味着线程不会死锁。