同步停放像Lock.lock（）这样的并发线程吗？ [英] Does synchronized park a concurrent thread like Lock.lock() does?

问题描述

当我们调用 lock.lock（）或尝试输入 synchronized 块时，我们的线程会阻塞其他一些线程已经采取了这种锁定。现在我的问题是，当我们查看 lock.lock（）的实现时，它委托获取锁定到实际停放当前线程的AQS（以便无法进一步调度by scheduler）。

同样的情况是 synchronized 阻塞了吗？

我甚至认为我的线程状态也不同。例如，如果我的线程在 synchronized 块被阻止，那么它将是 BLOCKING ，而如果我调用了
lock.lock（），然后它将 WAITING 。我是对的吗？

我关注的是 Thread.status 方面的以下两种锁定策略之间的区别通过停车而不是忙碌等待提高性能

1. ReentrantLock.lock（）;


2. 同步{/ *一些代码* /}

等待 - 在资源上被阻止，但是可以中断或通知或取消停放。

正如您所见，WAITING更适合从另一个处理过的控制。例如如果两个线程死锁，你可以用一个中断来打破一个lock（）。使用同步的两个线程，您将被卡住。

同步vs锁的行为非常相似，主要修订版之间的确切细节会发生变化。

我的建议是使用

• 同步更简单的代码，你需要线程安全但有一个非常低的锁争用。




• 使用Lock，你已经确定你有锁争用，或者你需要其他功能，如tryLock。

---

如果你这样做

  final Lock lock = new ReentrantLock（）; 
 lock.lock（）; 
线程t =新线程（新的Runnable（）{
 @Override 
 public void run（）{
 try {
 lock.lockInterruptibly（）; 
} catch（InterruptedException e）{
 e.printStackTrace（）; 
} 
} 
}）; 
 t.start（）; 
 Thread.sleep（100）; 
 System.out.println（t +is+ t.getState（））; 
 lock.unlock（）; 
  

打印

 线程[Thread-0,5，main]等待
  

Thread.State 陈述

---

等待线程的线程状态。由于调用以下方法之一，线程处于等待状态：

• 没有超时的Object.wait


• 没有超时的Thread.join


• LockSupport.park

一个帖子处于等待状态正在等待另一个线程执行特定操作。例如，在对象上调用Object.wait（）的线程正在等待另一个线程在该对象上调用Object.notify（）或Object.notifyAll（）。调用Thread.join（）的线程正在等待指定的线程终止。

When we call either lock.lock() or try to enter a synchronized block then our thread blocks if some other thread has already taken that lock. Now my question is, when we look at the implementation of lock.lock() it delegates acquiring lock to AQS which actually parks the current thread (so that it cannot be scheduled further by scheduler).

Is it the same case with synchronized blocking also?

I even think my thread status are also different. For example, if my thread is blocked on synchronized block it will be BLOCKING while if I have called lock.lock(), then it will be WAITING. Am I right?

My Concern is the difference between the below two locking strategies in aspects of Thread.status and performance improvement by parking instead of busy waiting

1. ReentrantLock.lock();
2. synchronize { /*some code */ }

解决方案

BLOCKING - is blocked on a resource, cannot be interrupted

WAITING - is blocked on a resource, but can be interrupted or notified or unparked.

As you can see WAITING is better for control from another processed. e.g. if two threads are deadlocked you could break a lock() with an interrupt. With a two thread using synchronized you are stuck.

The behaviour of the synchronized vs lock is very similar and the exact details change between major revisions.

My advise is to use

• synchronized for simpler code where you need thread safety but have a very low lock contention.

• use Lock where you have identified you have lock contention, or you need additional functionality like tryLock.

---

If you do

final Lock lock = new ReentrantLock();
lock.lock();
Thread t = new Thread(new Runnable() {
    @Override
    public void run() {
        try {
            lock.lockInterruptibly();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
});
t.start();
Thread.sleep(100);
System.out.println(t + " is " + t.getState());
lock.unlock();

prints

Thread[Thread-0,5,main] is WAITING

Thread.State states

---

Thread state for a waiting thread. A thread is in the waiting state due to calling one of the following methods:

• Object.wait with no timeout
• Thread.join with no timeout
• LockSupport.park

A thread in the waiting state is waiting for another thread to perform a particular action. For example, a thread that has called Object.wait() on an object is waiting for another thread to call Object.notify() or Object.notifyAll() on that object. A thread that has called Thread.join() is waiting for a specified thread to terminate.

这篇关于同步停放像Lock.lock（）这样的并发线程吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！