我正在为服务器编写侦听器线程，此刻我正在使用：

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

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

使用上面的代码，我遇到了运行功能吃掉所有cpu时间循环的问题。睡眠功能有效，但似乎是临时解决方案，而不是解决方案。

是否有一些函数会阻塞直到变量“ condition”变为“ true”？还是连续循环等待变量值改变的标准方法？

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

我假设您有另一个线程将做一些事情使该条件成立。有几种同步线程的方法。在您的情况下，最简单的方法是通过对象进行通知：

主线程：

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本身可以很简单Object。

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

EboMike的答案和Toby的答案都在正确的轨道上，但是它们都有致命的缺陷。该缺陷称为丢失通知。

问题是，如果一个线程调用foo.notify()，它将根本不做任何事情，除非某个其他线程已经在foo.wait()调用中处于休眠状态。对象，foo不记得它已收到通知。

有一个原因导致不允许您调用，foo.wait()或者foo.notify()除非线程在foo上同步。这是因为避免丢失通知的唯一方法是使用互斥量保护条件。完成后，它看起来像这样：

使用者线程：

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

生产者线程：

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

更改条件的代码和检查条件的代码都在同一对象上同步，并且使用者线程在等待之前显式测试条件。wait()当条件为真时，用户无法错过通知并永远陷入通话中。

另请注意，这wait()是一个循环。这是因为，在一般情况下，当使用者重新获取foo锁并唤醒时，其他一些线程可能再次使条件变为假。即使在您的程序中不可能做到这一点，在某些操作系统中，foo.wait()即使foo.notify()没有被调用也可能返回。这就是所谓的“伪唤醒”，它是允许发生的，因为它使等待/通知在某些操作系统上更容易实现。

由于没有人使用CountDownLatch发布解决方案。关于什么：

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

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

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

与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在内部同步上使用s有很多优点，但是我只喜欢使用一个显式Condition对象来表示条件（您可以拥有多个对象，这对于生产者-消费者这样的事物来说是很好的选择）。

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

这是因为如果引发异常，则中断状态标志将被重置（它的意思是“我不再记得被打扰，如果有人问我，我将无法告诉其他人我已经去过”），并且可能有另一个过程依靠这个问题。这个例子是其他东西基于这个this子实施了中断策略。另一个示例可能是您的中断策略，而while(true)不是已被实施为while(!Thread.currentThread().isInterrupted()（这也会使您的代码更加……具有社会影响力）。

因此，总而言之，Condition当您要使用a时Lock，using相当于使用wait / notify / notifyAll ，日志记录是邪恶的，吞咽InterruptedException是顽皮的;）

您可以使用信号量。

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

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

您也可以尝试使用SynchronousQueue或CountDownLatch。

无锁解决方案（？）

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

问题：我最多只有一个线程从队列中消耗。多个生产者线程不断插入队列中，并且需要在等待时通知使用者。该队列是无锁的，因此使用锁进行通知会导致生产者线程不必要的阻塞。每个生产者线程都需要先获取锁，然后才能通知正在等待的使用者。我相信我想出了使用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);
    }
}

为了给出模糊的用法示例，我将采用james large的示例：

SignalBarrier barrier = new SignalBarrier();

使用者线程（单数，而不是复数！）：

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

生产者线程：

doSomethingThatMakesConditionTrue();
barrier.signal();