是非题：锁是同步块，而锁是结构化编程？

如何解决是非题：锁是同步块，而锁是结构化编程？

|                                                                                                                       

解决方法

好吧，同步块比ReentrantLock之类的类早了很多年。引入了该包中的类，以提供比该语言以前提供的Java更先进的功能和高级功能，尽管其中许多功能仅在非常特殊的情况下才需要。 但是在这种情况下，我想说使用同步块（和用wait（N）代替sleep（N）！）会更优雅。我理解您的类比，并且我会说有时成立。当然，对于这种情况，使用同步块就像在C ++中使用RAII模式－这是确保在需要时进行清理的最清晰方法。     ,通常，设计性能良好（并执行）的并发数据结构是一项非常棘手的任务。如果您不使用低级工具自己实现所有事情，而是使用标准库中可用的更多高级抽象，则将其视为一件好事。 对于您的任务，我宁愿使用BlockingQueue或BlockingDeque来为我完成同步。     ,同步块本质上总是正确嵌套的，而您可能会滥用锁而忘记解锁。但是，关于锁的第一件事就是始终在try / finally构造中使用锁，如下所示：

lock.lock();
try {
    // Do things...
}
finally {
    lock.unlock();
}

强烈建议使用此模式，以确保您的锁表现为同步块。 与同步块相比，锁具有几个优点： 它们比同步块更有效，尽管我读到最近的JVM中已修复了该问题。 某些锁可以分为读写锁，以提高并发性。 它们可以传递，但是您就超出了上面解释的安全模式。 因此，恕我直言，锁更像是一门更大的枪：功能更强大，但如果您不知道如何使用它们，也将更加危险。     ,相同代码的修改版本，更适合IMO :)为了回答您的问题，类推是错误的。 gotos的声誉很差，因为它们让控制流逃逸的方式引起了噩梦。锁不允许控件以相同的方式转义。好吧，您可能会问，如果我获得一把锁并拒绝释放它，会发生什么情况。同步块无法使用。理想的模式是最终尝试使用。顺便说一句，并发编程本身就是一个噩梦，无法增强/减少。

while(true) {
    if(queue.size()==0){
        Thread.sleep(36000);
    }
    lock.lock();
    Vpacket p = null;
    try {
         p = null;
         if(queue.size()!=0) {
              p = queue.pop();
         }
    } finally {
         lock.unlock();
         if(p!=null) {
              return p;
         }
    }
}