java - 是否有更快版本的 SynchronousQueue 仅用于同步 2 个线程？

Question

我的应用程序中有一个情况，我需要启动一个异步任务，然后阻止它完成。 (是的，是的，我知道这不是最佳的，但它是我们正在使用的库的产物。)

具体来说，我需要调用一个函数并传递一个回调对象，实际的回调将在单独的线程上发生。但我想等待回调发生，本质上是在异步机制之上构建同步机制。

所以我的代码看起来像这样:

private static class MethodCallback implements RpcCallback<Message> {
    private Message message = null;
    private boolean done = false;
    private long started = System.currentTimeMillis();

    public synchronized void run(Message parameter) {
        long elapsed = System.currentTimeMillis() - started;
        log.debug("Got callback after {} millis", elapsed);
        this.message = parameter;
        this.done = true;
        notifyAll();
    }

    public synchronized void await() throws ServiceException {
        while(!done && (System.currentTimeMillis() - started < MAX_WAIT_MILLIS)) {
            try {
                long remaining = (started + MAX_WAIT_MILLIS) - System.currentTimeMillis();
                if(remaining <= 0) {
                    remaining = 1;
                }
                wait(remaining);
            } catch(InterruptedException e) {
                break;
            }
        }
        if(!done) {
            String msg = String.format("Timeout: No response from async process");
            log.warn(msg);
            throw new ServiceException(msg);
        }
    }

    public Message get() {
        return message;
    }
}

public Message getMessageFromAsyncProcess() {
    MethodCallback callback = new MethodCallback();
    channel.doAsyncThing(callback);
    callback.await();
    Message result = callback.get();
    if(result == null) {
        throw new ServiceException("Error: async process did not produce a result");
    }
    return result;
}

现在，这段代码运行得非常好，并且应用程序的执行速度也可以接受。但分析已确定 MessageCallback.run 是性能瓶颈，可能是由于同步所致。

因此，作为实验，我修改了代码以使用 SynchronousQueue相反，期望这会提高性能。但令我惊讶的是，它的运行速度慢了一倍(平均每次调用大约 15 毫秒，而硬方法版本每次调用大约 7 毫秒)。

我大概可以使用 Semaphore 破解替代机制或类似AtomicBoolean ，但是我应该期望其中任何一个会表现得更好吗？

鉴于我只有两个线程，并且我只是希望其中一个线程等待另一个线程产生单个结果，是否有任何机制比我现在所做的更好？

Answer 1

我猜测您使用的是时钟分辨率约为15 ms的Windows系统。我建议您尝试使用 System.nanoTime() 以获得更准确的计时。

最明显的解决方案是使用执行程序服务，该服务只需要几行代码即可完全实现您想要实现的目标。

您应该能够在来回传递任务的线程之间切换，时间大约为1 - 8 us(微秒)即使在负载下，您的最佳计时也应该在这个时间左右。

注意:您的 wait() 方法在获得锁之前不会唤醒(在 run() 完成之后)，这可能不是您想要的。