Algorithm

Distinct-Subsequences

Review

本周阅读：How the Actor Model Meets the Needs of Modern, Distributed Systems

本文主要描述Actor模式的模型、核心思想以及实现方式。

模型：Actor模型构建的程序由多个Actor组成，所有的Actor将组成一个有向无环图，信号与消息顺着图的边向前流动，依次触发各个Actor的行为，从而完成计算。

traditional-program-mode

上图为传统程序执行模型，依靠方法的不断入栈(调用)出栈(返回)驱动程序顺序执行 Actor-execute-model 上图为Actor执行模型，依靠消息在整个Actor中传递驱动程序顺序执行

该模型的优势：

  1. Actor状态都保存在内部，多个Actor之间通过消息通信，与多核处理器之间通过cache和内存进行消息传递的计算模型更加契合，效率也更高
  2. 通过解耦消息的传递过程与计算过程，Actor模型统一了同步/异步的计算模型，具体可由调度器根据具体需要自行选择
  3. 每一个Actor都是原子的，多个Actor之间不存在共享数据，从而使得整个系统完全无锁，执行效率得到了很大的提升
  4. 通过增加/删除Actor可方便的修改整个系统的逻辑；修改Actors的调度方式即可让Actor运行在任意多台设备上，通过cache/内存/网络传递消息没有任何不同，因此整个系统的可扩展性非常强

PS：Actor之间不会共享任何数据，而且只对消息做出反应，意味着Actor不能并行。那么对于缓存这种共享内存的操作，个人对于其适应性存在一定的疑问。

Tip

关于内存泄漏的一点反思

最近处理了一个线上的内存泄漏导致的OOM问题，原因很简单：Server在每次连接创建时将channel放入了缓存的ConcurrentHashMap中，但却在连接断开时没有remove。

定位处理完后，自己分析总结了一下容易造成内存泄漏的情况：

  1. 内存泄漏总是由未释放的引用所导致，因此可达性算法的根应重点关注：static变量，启动了的Thread对象，无限循环方法中的临时变量等
  2. 个别对象的未释放通常不会导致严重的OOM问题，容器以及容器中的对象才会
  3. 内存泄漏后，分析超多对象的数量关系与class定义，通常会有一定的意外惊喜（找到未释放对象根源的确切class定义）
  4. 将自带生命周期属性的对象放入容器时一定要慎之又慎，需要仔细分析对象生命周期结束时是否能够得到释放

Share

协程随想