是否存在“阻塞直到条件变为真”？ java中的函数？

Question

我正在为服务器编写一个侦听器线程，目前我正在使用：

while (true){
    try {
        if (condition){
            //do something
            condition=false;
        }
        sleep(1000);

    } catch (InterruptedException ex){
        Logger.getLogger(server.class.getName()).log(Level.SEVERE, null, ex);
    }
}

通过上面的代码，我遇到了 run 函数占用所有 cpu 时间循环的问题。睡眠功能可以工作，但这似乎只是权宜之计，而不是解决方案。

是否有一些函数会阻塞直到变量“条件”变为“真”？ 或者连续循环是等待变量值更改的标准方法？

Answer 1

像这样的轮询绝对是最不受欢迎的解决方案。

我假设您有另一个线程将执行某些操作以使条件成立。有多种方法可以同步线程。在您的情况下，最简单的一个是通过对象发出通知：

主线程：

synchronized(syncObject) {
    try {
        // Calling wait() will block this thread until another thread
        // calls notify() on the object.
        syncObject.wait();
    } catch (InterruptedException e) {
        // Happens if someone interrupts your thread.
    }
}

其他线程：

// Do something
// If the condition is true, do the following:
synchronized(syncObject) {
    syncObject.notify();
}

syncObject 本身可以是一个简单的对象。

线程间通信还有许多其他方式，但使用哪一种取决于您正在做什么。

Answer 2

EboMike 的回答和Toby 的回答< /a> 都在正确的轨道上，但它们都包含一个致命的缺陷。该缺陷称为丢失通知。

问题是，如果一个线程调用 foo.notify()，它根本不会执行任何操作，除非其他线程已经在 foo.wait() 调用中休眠。对象 foo 不记得它已被通知。

除非线程在 foo 上同步，否则不允许调用 foo.wait() 或 foo.notify() 是有原因的。这是因为避免丢失通知的唯一方法是使用互斥锁来保护条件。如果做得正确，它看起来像这样：

消费者线程：

try {
    synchronized(foo) {
        while(! conditionIsTrue()) {
            foo.wait();
        }
        doSomethingThatRequiresConditionToBeTrue();
    }
} catch (InterruptedException e) {
    handleInterruption();
}

生产者线程：

synchronized(foo) {
    doSomethingThatMakesConditionTrue();
    foo.notify();
}

更改条件的代码和检查条件的代码都在同一个对象上同步，并且消费者线程在等待之前显式测试条件。当条件已经成立时，消费者不可能错过通知并最终永远陷入 wait() 调用中。

另请注意 wait() 处于循环中。这是因为，在一般情况下，当消费者重新获取 foo 锁并唤醒时，其他某个线程可能再次使条件为 false。即使这在你的程序中是不可能的，但在某些操作系统中，即使 foo.notify( ) 尚未被调用。这称为“虚假唤醒”，它被允许发生，因为它使等待/通知更容易在某些操作系统上实现。

Answer 3

由于没有人发布 CountDownLatch 的解决方案。怎么样：

public class Lockeable {
    private final CountDownLatch countDownLatch = new CountDownLatch(1);

    public void doAfterEvent(){
        countDownLatch.await();
        doSomething();
    }

    public void reportDetonatingEvent(){
        countDownLatch.countDown();
    }
}

Answer 4

与 EboMike 的答案类似，您可以使用类似于 wait/notify/notifyAll 的机制，但准备使用 Lock。

例如，

public void doSomething() throws InterruptedException {
    lock.lock();
    try {
        condition.await(); // releases lock and waits until doSomethingElse is called
    } finally {
        lock.unlock();
    }
}

public void doSomethingElse() {
    lock.lock();
    try {
        condition.signal();
    } finally {
        lock.unlock();
    }
}

您将等待另一个线程通知的某些条件（在本例中调用doSomethingElse），此时，第一个线程将继续...

使用Lock< /code> 相对于内在同步有很多优点，但我只是更喜欢有一个显式的 Condition 对象来表示条件（您可以有多个对象，这对于生产者-消费者之类的事情来说是一种很好的接触） 。

另外，我忍不住注意到您如何处理示例中的中断异常。您可能不应该像这样使用异常，而是使用 Thread.currentThread().interrupt 重置中断状态标志。

这是因为如果抛出异常，中断状态标志将被重置（它表示“我不再记得被打断过，如果他们询问，我将无法告诉其他人我曾经被打断过”） >")，另一个过程可能依赖于这个问题。例子是其他东西已经基于此实施了中断策略......唷。另一个例子可能是您的中断策略，而不是 while(true) 可能已实现为 while(!Thread.currentThread().isInterrupted() （这将也让你的代码更加......社会考虑）

所以，总而言之，当你想使用 Lock 时，使用 Condition 大致相当于使用 wait/notify/notifyAll >，日志记录是邪恶的，吞下 InterruptedException 是顽皮的；）

Answer 5

您可以使用 信号量 。

当条件不满足时，另一个线程获取信号量。
您的线程将尝试使用 acquireUninterruptically()
获取它
或 tryAcquire(int Permits, long timeout, TimeUnit unit) 并将被阻止。

当条件满足时，信号量也会被释放，并且您的线程将获取它。

您还可以尝试使用 SynchronousQueue< /code> 或 CountDownLatch。

Answer 6

人们还可以利用 CompletableFuture（自 Java 8 起）：

final CompletableFuture<String> question = new CompletableFuture<>();

// from within the consumer thread:
final String answer = question.get(); // or: event.get(7500000, TimeUnit.YEARS)

// from within the producer thread:
question.complete("42");

Answer 7

无锁解决方案（？）

我有同样的问题，但我想要一个不使用锁的解决方案。

问题：我最多有一个线程从队列中消耗。多个生产者线程不断地向队列中插入数据，并且需要通知消费者是否正在等待。队列是无锁的，因此使用锁进行通知会导致生产者线程不必要的阻塞。每个生产者线程都需要先获取锁，然后才能通知等待的消费者。我相信我使用 LockSupport 和 AtomicReferenceFieldUpdater。如果 JDK 中存在无锁屏障，我找不到它。据我所知，CyclicBarrier 和 CoundDownLatch 都在内部使用锁。

这是我稍微缩写的代码。需要明确的是，这段代码一次只允许一个线程等待。可以修改它以允许多个等待者/消费者，方法是使用某种类型的原子集合来存储多个所有者（ConcurrentMap 可能有效）。

我已经使用了这段代码，它似乎有效。我还没有对其进行广泛的测试。我建议您阅读 LockSupport。

/* I release this code into the public domain.
 * http://unlicense.org/UNLICENSE
 */

import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
import java.util.concurrent.locks.LockSupport;

/**
 * A simple barrier for awaiting a signal.
 * Only one thread at a time may await the signal.
 */
public class SignalBarrier {
    /**
     * The Thread that is currently awaiting the signal.
     * !!! Don't call this directly !!!
     */
    @SuppressWarnings("unused")
    private volatile Thread _owner;

    /** Used to update the owner atomically */
    private static final AtomicReferenceFieldUpdater<SignalBarrier, Thread> ownerAccess =
        AtomicReferenceFieldUpdater.newUpdater(SignalBarrier.class, Thread.class, "_owner");

    /** Create a new SignalBarrier without an owner. */
    public SignalBarrier() {
        _owner = null;
    }

    /**
     * Signal the owner that the barrier is ready.
     * This has no effect if the SignalBarrer is unowned.
     */
    public void signal() {
        // Remove the current owner of this barrier.
        Thread t = ownerAccess.getAndSet(this, null);

        // If the owner wasn't null, unpark it.
        if (t != null) {
            LockSupport.unpark(t);
        }
    }

    /**
     * Claim the SignalBarrier and block until signaled.
     *
     * @throws IllegalStateException If the SignalBarrier already has an owner.
     * @throws InterruptedException If the thread is interrupted while waiting.
     */
    public void await() throws InterruptedException {
        // Get the thread that would like to await the signal.
        Thread t = Thread.currentThread();

        // If a thread is attempting to await, the current owner should be null.
        if (!ownerAccess.compareAndSet(this, null, t)) {
            throw new IllegalStateException("A second thread tried to acquire a signal barrier that is already owned.");
        }

        // The current thread has taken ownership of this barrier.
        // Park the current thread until the signal. Record this
        // signal barrier as the 'blocker'.
        LockSupport.park(this);
        // If a thread has called #signal() the owner should already be null.
        // However the documentation for LockSupport.unpark makes it clear that
        // threads can wake up for absolutely no reason. Do a compare and set
        // to make sure we don't wipe out a new owner, keeping in mind that only
        // thread should be awaiting at any given moment!
        ownerAccess.compareAndSet(this, t, null);

        // Check to see if we've been unparked because of a thread interrupt.
        if (t.isInterrupted())
            throw new InterruptedException();
    }

    /**
     * Claim the SignalBarrier and block until signaled or the timeout expires.
     *
     * @throws IllegalStateException If the SignalBarrier already has an owner.
     * @throws InterruptedException If the thread is interrupted while waiting.
     *
     * @param timeout The timeout duration in nanoseconds.
     * @return The timeout minus the number of nanoseconds that passed while waiting.
     */
    public long awaitNanos(long timeout) throws InterruptedException {
        if (timeout <= 0)
            return 0;
        // Get the thread that would like to await the signal.
        Thread t = Thread.currentThread();

        // If a thread is attempting to await, the current owner should be null.
        if (!ownerAccess.compareAndSet(this, null, t)) {
            throw new IllegalStateException("A second thread tried to acquire a signal barrier is already owned.");
        }

        // The current thread owns this barrier.
        // Park the current thread until the signal. Record this
        // signal barrier as the 'blocker'.
        // Time the park.
        long start = System.nanoTime();
        LockSupport.parkNanos(this, timeout);
        ownerAccess.compareAndSet(this, t, null);
        long stop = System.nanoTime();

        // Check to see if we've been unparked because of a thread interrupt.
        if (t.isInterrupted())
            throw new InterruptedException();

        // Return the number of nanoseconds left in the timeout after what we
        // just waited.
        return Math.max(timeout - stop + start, 0L);
    }
}

为了给出一个模糊的用法示例，我将采用 jameslarge 的示例：

SignalBarrier barrier = new SignalBarrier();

消费者线程（单数，不是复数！）：

try {
    while(!conditionIsTrue()) {
        barrier.await();
    }
    doSomethingThatRequiresConditionToBeTrue();
} catch (InterruptedException e) {
    handleInterruption();
}

生产者线程：

doSomethingThatMakesConditionTrue();
barrier.signal();