我有下面的代码，什么是理想的方式来正确地返回值从这个方法，使用React式redis操作，是为了作为一个共同的API从redis读取值。我可以写一些古怪的代码来管理这个，但只是想知道是否有一个很酷的方式，我可能会错过，感谢分享。
public Object getObject(final String key, final String hash) {
reactiveRedisCommands.hget(key , field ) //returns Mono<String>
.subscribe(
new Consumer<String>() {
@Override
public void accept(String value) {
//String value is obtained here and converted to object as per type and any additional processing that is required
}
});
return null;// how to return correct value here
}字符串
1条答案
按热度按时间r9f1avp51#
回调的关键是不能将结果提供给调用者;相反，结果将在一段时间后出现。
通常的解决方案是回调地狱：所有的异步方法都返回
void，而不是接受一个Consumer<X>，其中X是你在非异步世界中通常返回的。问题是代码往往会变成一堆乱七八糟的回调，堆在所有东西上。当你决定使用异步设置时，你就已经注册了。通常你不需要这样做（线程通常很好）。
Project Loom是Java上的工作的名称，使这些事情变得简单得多。非常现代的JVM（版本20）已经集成了loom的许多部分，但这一切基本上都是在今年发生的;许多框架还没有（到目前为止）使用loom来减少这种回调地狱的问题。所以，虽然今天是坏消息，但一两年内会好转。
在此之前，你只有三个选择：
1.重新开始并丢弃异步。很少值得。
1.让你的
getObject方法阻塞，直到结果可用。这并不是特别难写，但会使你的getObject方法在任何异步上下文中都是非法调用（异步上下文不允许阻塞！）。通常你得到未来，并要求Future等待，直到响应可用。如果你想处理这个功能，也可以通过创建一个锁对象并使用wait/notify来简单地编写这个功能。这通常是一个非常糟糕的主意，你现在混合了同步和异步，结果是灾难性的（灾难性的，如：在开发机器上运行良好，在生产环境中运行起来就像糖蜜一样，因为你在异步上下文中阻塞了）。1.重写这个方法，要么返回一个future，要么返回
void并接受一个直接传递给subscribe的Consumer<String> processor参数。