kat*_*ex7 2 java spring reactive-programming spring-boot project-reactor
我得到的是线程是非阻塞的,我们不需要根据N个并发请求进行线程扩展,而是将我们的任务放在我们的反应式Web编程模式中的单个事件循环中.
是的,这可以提供帮助,但由于事件循环是一个队列,如果要处理的第一个任务永远阻塞怎么办？然后事件循环将永远不会进展,从而结束响应和处理而不是排队更多任务.是的,超时可能是可能的,但我无法理解事件循环如何成为一个好的解决方案.
假设您有3个任务需要3秒钟等待IO并运行每个执行并且他们已经提交到事件队列.然后,他们仍然需要9秒才能处理,并且一旦IO解决就执行.在使线程阻塞的情况下,这将在3秒内解决,因为它们同时运行.
我可以看到的好处是,如果事件循环不是真正的队列,并且在发出任务准备好处理的信号时,它会调度要处理的任务.但是,在这种情况下,这将意味着不维护任务执行的顺序,并且每个任务必须仍然运行一个线程,以便能够分辨何时IO被解析.
也许我没有正确理解事件循环和线程处理.有人可以纠正我,因为看起来这个Reactor模式似乎让事情变得更糟.
最后,在Spring Reactor中的X请求中,只创建了一个线程来运行处理程序而不是传统的X线程吗？在这种情况下,如果有人意外地编写了阻止代码,那是不是意味着每个后续请求都会排队？
将事件循环用于长时间运行的任务并不是一个好主意.这被认为是一种反模式.通常它仅用于快速获取即将发生的事件,但如果工作会明显阻止事件循环,则实际上不会执行与这些事件相关的工作.您可能希望使用单独的线程池来执行长时间运行的任务.因此,事件循环通常只使用异步且因此非阻塞结构启动工作(或者只有在可以非常快速地完成工作时才实际工作)并将较重且可能阻塞的任务传递给单独的线程池(用于CPU密集型计算) )或操作系统(例如通过网络发送的数据缓冲区).
此外,不要被只有一个线程处理事件的事实所迷惑,它非常快,通常足以满足要求苛刻的应用程序.像NodeJS这样的平台或像Netty这样的框架(用于Akka,Play框架,Apache Cassandra等)正在使用事件循环,并取得巨大成功.人们应该意识到这样一个事实,即在事件循环中执行阻塞操作通常是一个坏主意.
有关更多信息,请查看其中一些帖子:
| 归档时间： |
|
| 查看次数： |
932 次 |
| 最近记录： |