回答我自己的问题只是分享我的想法，我想出了什么。
如果我们已经有了基于Servlets / Spring MVC的现有工作的Web应用程序，似乎通常没有什么好的理由转换到Actors / AKKA(或者介绍演员到现有的系统，只是为了攻击它)如果在我们的应用程序我们：
>没有：线程工作者的逻辑，当任务分裂在后台。 (通常是典型的Web应用程序没有这个)，像长时间的计算..
(并行)。
>有：如果我们有顺序调用 – 当一个组件调用另一个组件时，那么那个
呼叫另一个，呼叫依赖于彼此：像
控制器调用Component，Component将一些数据保存到某个List
(它是可变的，但同步为同步列表)。
>没有空闲时间来替换Akka演员的所有Spring控制器，或者使用不同的服务器(不是Tomcat)(没有太多的经理/产品所有者可以让你这样做)
演员在这个简单的系统中有什么问题？
>通过组件传递大量消息(通过组件传递命令的类)，而不是调用常规方法(使用OPP的优点，实现接口，具有多个实现 – 但是Actors通常是最终类)。
>将消息作为字符串，不是很好的解决方案 – 因为它很难调试。
>在这样一个系统(如mvc网站)中，通常没有太多的事情需要同步(它已经是无状态的)。通常每个控制器/组件中有0..2个可变共享数据。这不是很难同步(只是让习惯把同步的所有常见的东西和你的类的顶部共享(所以状态是可识别的/本地化的)有时你只需要同步收集或使用java的Atomic包装器类型。
当演员可能被用于现有的应用程序。用例可能是这样的：
>当我们有长期的搜索，这经历了几个来源(一种线程工作者)。有几个/拉MasterActor – > SiteSearchActor(就像计算PI here一样)。 MasterActor具有最终结果。 SiteSearchActor为多个客户端计算(对多个站点进行搜索)的位置。
>或当我们有任何线程叉，从当前的servlet中
>当我们确定/知道我们的系统将被数百万客户端使用(即使是简单的逻辑)，我们应该提前考虑可扩展性和性能(
>演员sacale好 – 我们可以将一件作品从一个演员委托给N-one。
> actor在处理线程时保护处理器类型(10000个客户端不需要10000个线程，在大多数情况下，有4个线程(与处理器核心的数量相同)
但是一般来说，我同意this关于并发和并行的文章。如果我有机会从头开始创建应用程序，那么在需要使用的时候，我将使用没有Servlet容器的Akka和关于消息(命令类)和OOP(在一般的Web应用程序中没有这么多的OOP)不管怎么说，但没有人阻止以OOP的方式保持一些业务逻辑，演员只是一个通讯胶)。这比使用JMS更好/更简单。
但是像我说的那样：
演员/ Akka对于：
>服务/控制器(而不是Servlet / SpringMVC)
线程工人喜欢逻辑
>特别是从零开始的项目(当前的基础设施并没有使你的行为者应用障碍)。
我现在唯一的问题是性能比较。假设我们知道：
having 10000 threads in one JVM with synchronized and locks for shared
mutable data in our MVC Controllers/Services are might be very bad
from the performance perspective. Since there are many possible locks,
threads that are concurrent (a rival or competitor for a hared
resource) to each other.
如果我们对于具有N的AKKA / Servlet有相同的场景(演员，其中N远小于1000)，我们很可能会有更好的表现(因为没有人阻挡任何人，除了队列本身，不需要从一个线程切换到另一个)。
但是即使有一个拥有10000个客户端的系统，用于基于Servlet的(线程模型)应用程序，使用100个客户端也可能会很好。如果我们有连接池(当然我们有)，它和Actor的队列(收件箱)的工作相同，调度客户端可以访问某些服务。它可以提高我们在K次的表现(其中K是更多的，如果我们没有池 – 让线拼写拼图)。
问题是：
对于现有的基于servlet的应用程序，是不是不适用AKKA的好理由？
Taking this a an argument: Even having old system on Servlers, with
connection pool may improve the performance to good level. And this
level, most likely, might be good enough in order NOT to apply AKKA to
existing Servlet application, like trying to change servlet model
(that’ supposed to be bad comparing to Controllers on top of AKKA).
这样思考是否有意义？
Consider connection pull is kind of INBOX (like in AKKA) scheduling the
commands (connection).
即使Servlet模型不好(处理通过连接池连接创建的其余(活动)线程中的锁)。
连接池可能是足够好的，当将akka与基于servlet的东西进行比较时，它将被遗忘。我们仍然可以调整我们的应用程序，改变连接池中的MAX-CONNECTION。通常，我们尽全力使应用程序成为无状态的，所以在大多数情况下，我们不同步任何东西。
但是当然，只有一个连接池用于整个应用程序是不好的。如果与Actors进行比较，每个actor都有各自的连接池(邮箱)，每个actor可能负责接受HTTP请求。那个模型肯定会更好。
附：
大多数情况下** Future **都够好了如果您希望“安全”存储其中的状态(与基本上不同)，演员是好的。
更新：
Some people认为使用演员是个坏主意。什么是好的 – 纯粹的功能方法或scalaz已经提供的东西(以及Haskell我猜)，但不是用于远程调用。