我们很难避免在 ECS 系统中相互引用 Entity 。而我对 ECS 模式的使用是鼓励去引用的。为此，我对许多常见依赖引用的模式给了对应的解决方案。
最近的一个 luaecs 开发版本中，提供了一种 Lua 层面的引用方案 ：在创建 Entity 时，可以指定一个 table 作为该对象的引用。系统会更新它，让它保持为一个有效的（形如 select 过程中的）迭代器。这样，业务层就可以随时通过它 sync entity 中的数据。
我一直不是太喜欢这个方案，所以一直再考虑不同的解决方法。念念不忘 必有回响。昨天，我尝试了一个新的、更满意一点的方案。
对象池（object pool pattern）是一种设计模式。一个对象池包含一组已经初始化过且可以使用的对象，而可以在有需求时创建和销毁对象。池的用户可以从池子中取得对象，对其进行操作处理，并在不需要时归还给池子而非直接销毁它。这是一种特殊的工厂对象。
若初始化、实例化的代价高，且有需求需要经常实例化，但每次实例化的数量较少的情况下，使用对象池可以获得显著的效能提升。从池子中取得对象的时间是可预测的，但新建一个实例所需的时间是不确定。
另外，利用对象池，我们可以重用对象，减少对象的分配，对于垃圾回收的编程语言，也是一种提高性能的手段。
Python是一门备受推崇的脚本语言，以其简单的语法和全面的功能而著称，可快速实现各种业务。本文从 CPython 对象构造器入手，介绍了浮点数对象在 CPython 底层数据结构中的表现形式以及对象创建的过程。通过进一步了解 CPython 动态性的实现方式，读者可望在阅读 CPython 源码后提升编写高质量代码的能力。
谈论到引用透明(Referential Transparency)，我们都会聊函数式编程(FP)，会聊Effect和Side Effect，会聊纯函数(Pure Function)等，这些概念相互关联，有时甚至彼此引用定义，能够真正理解它们的含义非常重要。
在本教程中，我们将了解如何在 Java 中查找对象的内存地址。
在此之前，我们需要说明的是，运行时数据区的内存布局不是 JVM 规范的一部分，完全由实现者自行决定。因此，每种 JVM 可能回用不同的策略布局内存中的对象和数组。
在本教程中，我们主要讨论 HotSpot JVM。
目前，我们用 ECS 管理游戏引擎中的对象。当游戏场景大到一定程度，就需要有一个机制来快速筛选出需要渲染的对象子集。换句话说，如果你创建了 100K 个 Entity ，但是只有 1K 个 Entity 需要同时渲染，虽然遍历所有可渲染对象的成本最小是 O(n) ，但这个 n 是 100K 这个数量级，还是 1K 这个数量级，区别还是很大的。
我们的 ECS 系统已经支持了 tag 这个特性，可以利用 visible tag 做主 key 快速筛选可见对象。但当镜头移动时，需要重置这些 tag 又可能有性能问题。重置这些 visible tags 怎样才能避免在 100K 这个数量级的 O(n) 复杂度下工作？
这里不再介绍其他 Builder 实现方式，直接祭出最实用的通用Builder：
适用于所有类，不需要改造原来类，不需要 lombok 插件支持。
先看看使用姿势：
ECS 模式下最难处理的是同类 Component 之间有相互联系的情况。
最方便 ECS 处理的数据是相互独立的，每个数据单元都不和其它数据单元产生联系；如果多个数据单元会有故有的联系时，当可以把它们看作是同一个实体（Entity）下的不同组件（Component）时，那么就可以借用 Entity 的概念来处理它们。我们依旧可以按固定的次序去迭代这些数据。
但是，在复杂系统中，无可避免的，同类数据相互之间也可以产生联系。例如：场景管理中，节点之间有父子关系，计算节点的空间状态的过程对数据的遍历次序有要求。且计算过程还需要访问父节点的状态。解决这类需求是 ECS 框架的一大挑战。
Redis 内部使用一个 RedisObject 对象来表示所有的 key 和 value，RedisObject 中的 type，则是代表一个 value 对象具体是何种数据类型，它包含字符串（String）、链表（List）、哈希结构（Hash）、集合（Set）、有序集合（Sorted set）。
