Java 执行io时akka jvm线程与os线程

我在这个网站上搜索了一些帮助来理解这一点，但还没有找到任何超级清晰的东西，所以我想我应该发布我的用例，看看是否有人可以提供一些信息

我对在akka中使用io操作时jvm线程与os线程的伸缩性有一个疑问。从akka网站：

Akka支持事件驱动轻量级线程的调度程序，允许在单个工作站上创建数百万个线程，以及基于线程的参与者，其中每个调度程序绑定到一个专用的OS线程

基于事件的参与者目前每个参与者消耗约600字节，这意味着您可以在4G RAM上创建650多万个参与者

在这种情况下，你们能帮助我理解在只有一个处理器的工作站上这是多么重要（为了简单起见）。因此，在我的示例用例中，我想获取一个包含1000个“用户”的列表，然后查询一个（或多个）数据库，以获取关于每个用户的各种信息。因此，如果我将这些“get”任务中的每一个分派给一个参与者，而该参与者将执行IO，那么该参与者不会基于工作站的os线程限制而阻塞吗

在这样的场景中，akka演员模型是如何让我振奋的？我知道我可能遗漏了一些东西，因为我对虚拟机线程与操作系统线程的相互作用不太了解，所以如果这里的一位聪明人能为我解释清楚，那就太好了

如果我使用Futures，我不需要使用wait（）或get（）来阻止并等待回复吗

在我的用例中，不管参与者是谁，它是否会“感觉”到我正在进行1000个连续的数据库请求

---

如果代码剪报有助于我理解这一点，Java将是首选，因为我仍在加快scala语法的速度，但是一个很好的清晰文本解释，说明这些数百万线程如何在单处理器机器上进行互操作，同时执行数据库IO也很好。

很难弄清楚您在这里真正想问什么，但这里有一些提示：

• 如果您在现代JVM上运行，Java线程和OS线程之间通常存在一对一的关系。（IIRC、Solaris允许您以不同的方式执行此操作……但这是例外。）

• 使用线程或任何构建在线程之上的东西所能获得的实际并行量受应用程序可用的处理器/内核数量的限制。除此之外，您将发现并非所有线程都在任何给定的时刻实际执行

• 如果有1000个参与者都试图“同时”访问数据库，那么他们中的大多数实际上都在等待数据库本身或线程调度程序。这是否等于发出1000个连续请求（即严格序列化），将取决于数据库和参与者正在执行的查询/更新

底线是计算机系统对可用于做事情的资源有严格的限制；e、 g.处理器数量、处理器速度、内存带宽、磁盘访问时间、网络带宽等。您可以设计一个应用程序，使其在使用可用资源的方式上更加智能，但您无法让它使用比实际更多的资源

---

在阅读你引用的文本时，在我看来，它是在谈论两种不同类型的演员：

基于线程的参与者与线程有1对1的关系。4Gb内存中不可能有数百万这样的演员

基于事件的参与者的工作方式不同。他们通常会坐在队列中等待事件发生，而不是一直有一个线程。发生这种情况时，事件处理线程将从队列中抓取参与者，并执行与事件关联的“操作”。操作完成后，线程移动到另一个参与者/事件对上

引用的文本表示，基于事件的参与者的内存开销约为600字节。它们不包括事件线程。。。因为事件线程由多个参与者共享

---

---

现在我不是Scala/Actors方面的专家，但很明显，在使用基于事件的Actors时，有些事情应该避免。例如，您可能应该避免直接与外部数据库对话，因为这可能会阻塞事件处理线程。

我认为可能是输入错误。我想他们是想说：

Akka支持事件驱动的轻量级参与者的调度程序， 允许在单个工作站上创建数百万个参与者，以及基于线程的参与者，其中每个参与者都绑定到一个专用的操作系统线程

---

事件驱动的参与者使用一个线程池——所有（可能有数百万）参与者共享同一个线程池。我对Akka actors不太熟悉，但通常情况下，您不会希望使用事件驱动的actors执行阻塞I/O，否则可能会导致饥饿

如果这是真的：……Java线程和OS线程之间通常存在一对一的关系。。。那么这有什么意义呢：…你可以在4GRAM上创建650多万个演员…好吧，那么我可能一直在想这个问题。我只是听到“演员”和“伟大的并发”交织在一起，但我不应该认为所有的演员都在同时行动，这是我的头脑的方向。这意味着“基于事件的演员”不是线程。他们只在处理事件时使用线程。啊，如果这是一个打字错误（这是有道理的），那么这本身就有助于把事情弄清楚一点。如果一个基于参与者的解决方案确实需要执行IO，那么您是否只有一个参与者来处理所有这些请求？您可以使用多个参与者，但您将使用基于线程的参与者。事实上，我认为这句话有第三个拼写错误，请看我上面的最新引用。+1-是的，哈