Activiti流程定义缓存源码分析2

1. 1. 缓存架构

根据Activiti流程定义缓存源码分析1代码分析，我们看到了大部分缓存处理类的类型为DeploymentCache，该接口的类图如图x-所示。

 

图x-部署缓存DeploymentCache

在上图中，我们很清晰的看到了DeploymentCache接口的定义以及具体实现类，通过后续的学习，你会逐渐掌握每个类的作用。那么，让我们先了解一下上图中各个类的作用。

1. DefaultDeploymentCache：该类对接口DeploymentCache中的方法进行实现，其内部使用Map数据结构维护所有的缓存数据，包括使用HashMap以及LinkedHashMap（LRU算法实现的基石）。

1. DeploymentCache：定义了对缓存数据的添加、获取、移除以及清除所有缓存数据的函数。

在这里可能读者有个小小的疑问，为什么没有定义对缓存的更新以及删除函数呢？其实道理也很简单，因为该接口中的默认实现类内部均使用Map数据结构来维护缓存中的数据，基于Map数据结构的特性，如果用户期望更新或者删除操作，只需要根据key调用add函数即可完成对原有值的更新覆盖操作，因此没有必要在该接口中单独定义更新和删除两个函数。这样设计的话，可能用户自定义的缓存处理类中的添加函数功能需要丰富一点，最起码要包括添加、更新和删除三个逻辑的判断和实现。需要注意一点：比如随后章节中我们在讲解重新部署流程文档的案例中，需要更新缓存中的数据，可能有些读者在平时的开发中喜欢使用clear函数进行缓存数据的清除操作，使用clear函数清除缓存数据，归根结底是对Actviti中的缓存处理机制不了解所导致的误操作。因为该操作会清除缓存中所有的数据，如果项目中流程定义文档比较多，缓存对象势必会非常的多，如果贸然调用clear函数清除所有的缓存，极易导致缓存雪崩，程序性能急剧下降，因此笔者强烈不推荐使用clear函数清除缓存数据，最好使用add函数进行缓存的添加、更新以及删除操作，当然了如果读者觉得有必要，也可以通过扩展接口的方式对更新或者删除的方法进行重新实现。

1. MultiSchemaMultiTenantProcessDefinitionCache：该类主要负责对“多数据库多租户路由”创建的流程引擎配置类中的部署对象进行缓存。

2. 技术团队支持：盘古BPM工作流平台

   具体效果参考盘古BPM