14 | Lock和Condition（上）：隐藏在并发包中的管程

精选留言(75)

• 

  　

  我觉得:不会出现死锁，但会出现活锁

  作者回复: 👍

  2019-03-30

   1

   36
• 

  xiyi

  存在活锁。这个例子可以稍微改下，成功转账后应该跳出循环。加个随机重试时间避免活锁

  作者回复: 👍👍👍
  

  2019-03-30

  

   28
• 

  bing

  文中说的公平锁和非公平锁，是不按照排队的顺序被唤醒，我记得非公平锁的场景应该是线程释放锁之后，如果来了一个线程获取锁，他不必去排队直接获取到，应该不会入队吧。获取不到才进吧

  作者回复: 是的，高手👍👍👍
  

  2019-03-30

  

   28
• 

  小华

  有可能活锁，A，B两账户相互转账，各自持有自己lock的锁，都一直在尝试获取对方的锁，形成了活锁

  作者回复: 👍
  

  2019-03-30

   1

   20
• 

  刘晓林

  1.这个是个死循环啊，有锁没群，都出不来。
  2.如果抛开死循环，也会造成活锁，状态不稳定。当然这个也看场景，假如冲突窗口很小，又在单机多核的话，活锁的可能性还是很小的，可以接受

  作者回复: 👍👍👍
  

  2019-03-30

  

   11
• 

  Q宝的宝

  老师，本文在讲述如何保证可见性时，分析示例--“线程 T1 对 value 进行了 +=1 操作后，后续的线程 T2 能否看到 value 的正确结果？“时，提到三条Happen-Before规则，这里在解释第2条和第3条规则时，似乎说反了，正确的应该是，根据volatile变量规则，线程T1的unlock()操作Happen-Before于线程T2的lock()操作，所以，根据传递性规则，线程 T1 的 value+=1操作Happen-Before于线程T2的lock()操作。请老师指正。

  作者回复: 火眼金睛👍👍👍👍，这就改过来
  

  2019-03-30

   1

   11
• 

  姜戈

  我也觉得是存在活锁，而非死锁。存在这种可能性：互相持有各自的锁，发现需要的对方的锁都被对方持有，就会释放当前持有的锁，导致大家都在不停持锁，释放锁，但事情还没做。当然还是会存在转账成功的情景，不过效率低下。我觉得此时需要引入Condition，协调两者同步处理转账！

  作者回复: 用condition会更复杂
  

  2019-03-30

  

   8
• 

  linqw

  class Account {
    private int balance;
    private final Lock lock
            = new ReentrantLock();
    // 转账
    void transfer(Account tar, int amt){
  boolean flag = true;
      while (flag) {
        if(this.lock.tryLock(随机数，NANOSECONDS)) {
          try {
            if (tar.lock.tryLock(随机数，NANOSECONDS)) {
              try {
                this.balance -= amt;
                tar.balance += amt;
  flag = false;
              } finally {
                tar.lock.unlock();
              }
            }//if
          } finally {
            this.lock.unlock();
          }
        }//if
      }//while
    }//transfer
  }
  感觉可以这样操作

  作者回复: 点个大大的赞！不过还可以再优化一下，如果阻塞在tar.lock.tryLock上一段时间，this.lock是不能释放的。

  2019-04-07

   3

   7
• 

  羊三@XCoin.AI

  用非阻塞的方式去获取锁，破坏了第五章所说的产生死锁的四个条件之一的“不可抢占”。所以不会产生死锁。
  
  用锁的最佳实践，第三个“永远不在调用其他对象的方法时加锁”，我理解其实是在工程规范上避免可能出现的锁相关问题。

  作者回复: 是的
  

  2019-03-30

  

   6
• 

  海鸿

  突然有个问题：
  cpu层面的原子性是单条cpu指令。
  java层面的互斥（管程）保证了原子性。
  这两个原子性意义应该不一样吧？
  我的理解是cpu的原子性是不受线程调度影响，指令要不执行了，要么没执行。而java层面的原子性是在锁的机制下保证只有一个线程执行，其余等待，此时cpu还是可以进行线程调度，使运行中的那个线程让出cpu时间，当然了该线程还是掌握锁。
  我这样理解对吧？

  作者回复: 对

  2019-03-30

  

   5
• 

  朱小豪

  应该是少了个break跳出循环，然后这个例子是会产生死锁的，因为满足了死锁产生的条件。

  作者回复: 加了break，也会有活锁问题，不加的话我觉得也是活锁，因为锁都会释放
  

  2019-03-30

  

   5
• 

  小予

  1、转账成功跳出循环，避免死循环
  2、锁自己账户时，加一个随机等待时间，避免活锁
  3、锁目标账户时，锁不到则直接解锁
  class Account {
  private int balance;
  private final Lock lock = new ReentrantLock();
      // 转账
      void transfer(Account tar, int amt){
  while (true) {
  if(this.lock.tryLock(随机数，NANOSECONDS)) {
  try {
  if (tar.lock.tryLock()) {
  try {
  this.balance -= amt;
  tar.balance += amt;
  // 转账成功结束循环
  break;
  } finally {
  tar.lock.unlock();
  }
  }//if
  } finally {
  this.lock.unlock();
  }
  }//if
  }//while
      }//transfer
  }

  2019-07-17

   1

   4
• 

  Liam

  1 不会出现死锁，因为不存在阻塞的情况
  2 线程较多的情况会导致部分线程始终无法获取到锁，导致活锁

  作者回复: 👍
  

  2019-03-30

  

   4
• 

  tdytaylor

  老师，关于这个问题，我思考之后觉得不会出现死锁，但是没看出为什么会出现活锁

  作者回复: 想想对面相遇的两个人互相谦让的例子看看

  2019-05-15

  

   3
• 

  江湖夜雨

  终于理解最后一道题出现活锁问题了，两个线程同事执行，线程A获取了u1.trylock，线程B获取了u2.trylock，线程A尝试获取u2.trylock，不能成功，线程A结束，同时线程B尝试获取u1.trylock，不能成功，线程B结束，又开始新的一轮，这样一直循环下去！

  2019-07-28

  

   2
• 

  朱小豪

  本文最后的例子，不明白为什么要用while true而且没有跳出循环，这不是死循环吗

  2019-03-30

  

   2
• 

  兔2🐰🍃

  volatile 变量规则：【unlock()对state的写操作 happens-before其他线程lock() 对 state的读操作，】所以线程 T1 的 unlock() 操作 Happens-Before 线程 T2 的 lock() 操作；
  这样会不会更容易理解些？

  2019-09-06

  

   1
• 

  zyz

  老师，lock是用aqs实现的，aqs是用了volatile＋cas操作系统原子操作保证线程安全的，这个也是管程吗？

  作者回复: 是管程的实现

  2019-08-21

  

   1
• 

  Fortune

  唉，到实践部分就懵逼了，前面理论还没消化，实践部分理解不是很透，不适合没有用过或者没有对并发包API理解的人，我太难了。。。。

  2019-08-01

  

   1
• 

  倚梦流

  会出现活锁和死循环，老师你好，这是我的优化后的代码，运用了之前学过的知识，优先获取id值比较小的资源，请老师指点是否有不足之处，谢谢！
      void transfer6(Account tar,int amt){
          boolean isOver=false;
          Account left=this;
          Account right=tar;
          if(left.id>right.id){
              left=tar;
              right=this;
          }
          Thread th=Thread.currentThread();
          while (!th.isInterrupted() && !isOver){
              if(left.lock.tryLock()){
                  try{
                      if(right.lock.tryLock()){
                          try{
                              System.out.println("账号："+this.id+"开始转账啦！,转出金额："+amt);
                              if(this.balance>=amt){
                                  this.balance-=amt;
                                  tar.balance+=amt;
                                  System.out.println("转账成功！");
                              }else{
                                  System.out.println("转账失败，余额不足！");
                              }
                              isOver=true;
                              System.out.println("转入账号:"+this.id+" 余额："+this.balance);
                              System.out.println("转出账号:"+tar.id+" 余额："+tar.balance);
                              System.out.println("转账结束！");
                          }finally {
                              right.lock.unlock();
                          }
                      }
                  }finally {
                      left.lock.unlock();
                  }
              }
          }
      }

  作者回复: 👍加个随机等待就更好了

  2019-07-06

   2

   1