TPriorityQueue[A] 是一个可以参与 STM 事务的可变队列。一个 TPriorityQueue 中包含了类型为 A 的带有顺序定义的值。与 TQueue 不同，take 返回的是最高优先级（指定顺序中的第一个）值，而不是队列中的第一个值。当从队列中取出时，不保证共享相同优先级的元素的顺序。 创建一个 TPriorityQueue 您可以使用 empty 函数创建一个空的 TPriorityQueue： 请注意，TPriorityQueue 的创建使用了隐式 Ordering。默认情况下，take 将返回指定顺序中第一个的值。例如，在按时间排序的事件队列中，最早的事件将被首先取出。如果您想要不同的行为，可以使用自定义的 Ordering。 您还可以使用 fromIterable 或 make 构造函数创建一个使用指定元素初始化的TPriorityQueue。fromIterable 构造函数采用 Iterable，而 make 构造函数采用可变参数元素序列。 向 TPriorityQueue 添加元素 您可以使用 offer 或 offerAll 方法将元素添加入 TPriorityQueue。如果您要同时向队列添加多个元素，则 offerAll 方法会更加高效。 从 TPriorityQueue 中获取元素 使用 take 从 TPriorityQueue 中获取一个元素。take 在语义上会阻塞，直到队列中至少要取一个值为止。您还可以使用 takeAll 立即获取队列中当前的所有值，或使用 takeUpTo 立即获取队列中指定数量的元素。 您也可以使用 takeOption 方法从队列中获取第一个值（如果不存在也不会被挂起），或者使用 peek 方法观察队列中的第一个元素（如果存在）而不将其从队列中删除。 有时，您想要对队列的当前状态进行快照而不修改它。为此，toChunk 组合器或其变体 toList 或 toVector 非常有用。这些函数将返回一个不可变的集合，该集合由当前队列中的所有元素组成，而队列的状态保持不变。 TPriorityQueue 的大小 您可以使用 size 方法检查 TPriorityQueue 的大小：
by 王继TMap[A] 是一种可以参与 STM 事务的可变映射。 创建一个 TMap 创建一个空的 TMap: 或创建具有指定值的 TMap： 或者，您可以通过提供的元组集合来创建 TMap： 将键值对存入一个 TMap 可以通过以下方式将新的键值对添加到 map 映射： 在 map 中添加条目的另一种方法是使用 merge： 如果该键不存在于 map 中，则其行为类似于简单的 put 方法。否则，使用提供的函数将现有值与新值合并。 从 TMap 中删除元素 从 TMap 中删除键值对的最简单方法是使用采用 delete 删除某个键： 同样，它可以删除满足函数参数的每个键值对： 或者，您可以保留所有与函数参数匹配的键值对： 请注意，retainIf 和 removeIf 与 filter 和 filterNot 具有相同的目的。但是分别命名它们的原因是要强调其本质上存在的区别。也就是，retainIf 和removeIf 都是破坏性的，调用它们会修改原集合。（而 filter 和 filterNot 只是返回新集合而不修改原集合） 从 TMap 中读取 可以通过以下方式获取与键关联的值： 或者，如果 map 映射中不存在该键，则可以提供默认值： 转换 TMap 中的条目 函数 transform((K, V) => (K, V)) 可以用于为 map 映射中的每一个条目计算新的值： 请注意，它也可以用来压缩 TMap： TransformM 可以用于效果化地映射条目： 函数 transformValues(V => V) 可以为 map 中的每个值计算一个新值： 可以通过 transformValuesM 效果化地处理 map 中的这些值： 请注意，transform 和 transformValues 的用途与 map 和 mapValues 相同。 之所以分别命名它们的原因是要强调其本质上的区别。也就是说，transform 和 transformValues 都是破坏性的，调用它们可以修改原集合。 fold 使用指定的两个关联运算来遍历折叠 TMap 中的元素： foldM 可以效果化地折叠原属： 对 TMap 键值对执行side effect计算 foreach 用于对映射中的每个键值对执行 side-effect 计算： 检查 TMap 中的成员 检查键值对是否存在于 TMap 中： 将 TMap 转换为 List 可以通过以下方式转换成元组列表： 可以按如下方式获得键列表： 可以按以下方式获得值列表：
TArray 是可以参与 STM 事务的可变引用的数组。 创建一个 TArray 创建一个空的 TArray: 或创建具有指定值的 TArray： 或者，您可以通过指定的集合来创建 TArray： 从 TArray 读取值 可以通过以下方式获得数组的第 n 个元素： 访问不存在的索引会引发 ArrayIndexOutOfBoundsException 异常并中止事务。 更新 TArray 中的值 可以按照以下步骤更新数组的第n个元素： 可以通过 updateM 效果化地更新数组的第n个元素： 更新不存在的索引会引发 ArrayIndexOutOfBoundsException 并中止事务。 转换 TArray 的元素 transform(A => A) 函数可以为数组中的每一个元素计算新值： 可以通过 transformM 效果化地映射元素： fold 通过两个指定的运算遍历折叠 TArray 中的元素： 可以通过 foldM 效果化地进行遍历折叠： 对 TArray 元素执行 side-effect 运算 foreach 用于对数组中的每个元素执行 side-effect 运算：
ZLayer[A, E, B] 描述应用程序的一层：应用程序中的每个层都需要一些服务（作为输入）并产生出一些服务（作为输出）。Layers 可以被视基于给定他们的依赖关系（其他服务）而产生这些服务绑定所需要的清单。 层的构造可以使资源的使用效果化，并且使资源被安全地获取，使用完后安全地释放。 默认情况下，层（Layer）是共享的，这意味着如果同一图层使用两次，则该图层将仅分配一次。由于层具有出色的可组合性，因此它们是 ZIO 中创建依赖于其他服务的服务的惯用方式。 最简单的 ZLayer 应用 具有依赖项的 ZLayer 应用 复杂的 ZLayer 依赖案例
Chunk[A] 代表一大块类型为 A 的值。块的设计块通常由数组支持，但向下层元素公开纯函数式的，安全的接口，并且它们对使用数组代价高昂的操作（例如重复级联）采用懒模式。 新建一个块（chunk） 块连接(Concatenating): ++ 操作返回当前块与指定块的串联块。例如： 块搜集(collecting): collect 过滤、映射块中的元素并返回新的块。以下是如何使用 collect 函数从Chunk[A] 中挑选所有字符串的例子： 如何使用 collect 函数从 Chunk[A] 中挑选所有数字[A]： collectWhile （从左到右）收集元素，直到选择条件首次返回“ false”： 或者另外一个例子： 块删除(dropping)： drop 函数从块中删除前 n 个元素。 dropWhile 依据条件函数删除所有返回 true 的元素： 块比较(Comparing): 块转换(Converting) toArray 将一个块转换成 Array。 toSeq 将一个块t转换成 Seq。
Stream[E, A] 表示一个可以产生 A 类型输出值，或可能以 E 类型为失败值的，效果化的流。 新建 Stream 或产生自 Iterable： 转换一个 Stream ZIO Stream 提供了许多标准的转换函数，例如：map，partition，grouped，groupByKey，groupedWithin等。以下是如何使用它们的示例。 map partition partition 根据函数参数将 stream 分成多个流元组。第一个流包含评估为 true的所有元素，第二个流包含评估为 false 的所有元素。较快的流可能比较慢的流领先，领先的程度受缓冲大小的限制。两个流都以 ZManaged 类型打包。在下面的示例中，左流仅包含偶数。 grouped 可以使用分组（grouped）函数将流的结果划分为指定的块大小。 groupByKey 可以使用 groupByKey 或 groupBy，按函数的执行结果对流进行分区。在下面的示例中，检查的结果被分组并计数。 groupedWithin groupedWithin 允许按时间或块大小对事件进行分组，以先满足者为准。在下面的示例中，每个块均最多包含 30 个元素，并且每 3 秒生成一次。 消费一个 Stream 使用 Sink Sink[E, A0, A, B] 表示接受的消费类型为 A，最终产生或者 E 型的错误， B 型的成功结果，以及剩余的类型为 A0。 例如，您可以使用 Sink.foldLeft 将 Stream 中的数据累加到单一个 ZIO 值： 在多个流上工作 您可以使用合并方法合并多个流： 或合并（zip）多个流： 然后您可以将流中的原属合并为单个 ZIO 值： 流压缩 解压 如果您读取到 Content-Encoding: deflate, Content-Encoding: gzip 或其它此类压缩数据流，则以下转换器可能会有所帮助： inflate 转换器可以根据 RFC 1951 标准对 deflated 格式的压缩输入流进行解压缩。 gunzip 转换器可以根据 RFC 1952 标准对 gzipped 格式的压缩输入流进行解压缩。 如果输入未经过正确的压缩，这两种解压缩方法都将以 CompressionException 作为失败类型。 压缩 deflate 转换器根据 RFC 1951 标准对流中的字节进行压缩。
ZSink[R, E, A, B] 用于消费从流中产生的元素。您可以将此接收器视为消费可变数量的 A 元素（可能为 0、1或很多！）的函数，可能因 E 类型错误而失败，或最终产生 B 类型的值。 ZSink 被作为参数传递给 ZStream#run： 建立 sinks zio.stream 提供了多种不同的 sink 供使用。 将数据收集到 Chunk[A] 中： 尝试将第一个元素接收到一个 Option 中（如果流为空则返回 None）： stream.runDrain 的以下实现将忽略流中所有的输入： 产生一个给定类型的失败： 基本的接收数据累积函数： 具有短路功能的折叠器： sinks 转换 创建 Sink 后，我们可以使用提供的操作对其进行转换。 并行运行两个接收器并返回先执行完成的那一个： 我们可以使用 contramap，通过给定 C => A，其中 C 是输入类型，而 A 是 Sink的接收的元素类型，将给定的输入转换为某个特定的 Sink dimap 是 contramap 的扩展，它还可以指定 Sink 的输出转换：
在 OO 中如果我们要实现某种“行为”，一般来讲我们会采用在 interface 或抽象基类中定义方法，然后在子类中实现方法的做法，这也是 OO 所倡导的“继承”和“重写”。假设我们现在要写一个“超级玛丽”游戏，在这个游戏中我们当然要实现一个 Mario，并且这个 Mario 至少需要会 move 和 Jump，也就是说我们肯定需要这样两个方法。并且考虑到游戏中肯定不止只有 Mario 会跑会跳，很多怪物也都会，所以我们需要设计一个叫 Npc 的基类，并且在这里定义一些虚函数，于是我们得到这样一个实现： So far so good. 可是写着写着我们发现，其实并不是每一个 Monster 都会 jump，比如 Mushroom就不会 jump，可是因为我们将 jump 这个方法定义在了基类里，这导致我们不得不为每一个怪物都实现 jump方法，这显然就不合适了，为了应对这一个小小的挑战，Easy! 我们只需对对象进行重构，将 jump方法拆出来单独放在一个 interface里就可以了，修改后我们得到一个新的 Jumpable interface，它包含了从 Npc 里面拆出来的 jump 方法： Mario 也调整为： 而 Mushroom 就可以实现为： 这样看上去好多了。 Continue… 接着我们遇到一个新的挑战，我们发现有些怪物不仅会走，而且会飞！参考之前的例子，我们又实现了一个 Flyable interface 成功地解决了这个问题。到目前为止 一切都还在 OO 的轨道上正常运行。接下来我们又遇到了一个挑战：我们要实现一个会“变形”的怪物，这个怪物初期的时候会飞，可是在遭打打击后会失去飞的能力但是获得走的能力，我们需要再次重构能力之间的关系，……并且不断有新的怪物出现，有些怪物可能只会飞，有的会游泳……，甚至我们还遇到连最基本的 move 都不会的怪物，比如“食人草” ……随着不断地重构，我们会发现我们陷入了重构陷阱，我们需要不断从基类中分离出新的接口，也可能将新的方法添加到基类中去。而每次对基类的改动都会造成巨大的扰动，这种扰动随着代码规模的扩大，修改也越来越困难。甚至有些方法，它们需要同时出现在没有继承关系的两个对象中，这种需求通过重构基类都无法解决。 为什么会出现这样的麻烦呢？这是因为 OO 强调的高内聚加强了方法之间的耦合，而这种耦合对程序是有害的，我们很难在设计的初期就对未来功能的耦合性做很好的预测，特别是对具有版本演进的应用而言，这种前瞻性是很难一步做到位的。这就使我们不断进入重构陷阱。有没有一种方法让我们避免这样的陷阱呢？答案就是接下来介绍的“鸭类”(duck mode)模型。 先介绍“鸭类”这个名称的来源。假设我们需要得到一只鸭子，先思考一下凭什么我们认为“它”将会是一只合格的鸭子呢？可能最初我们只需要它会游泳，并且它会“嘎嘎”叫就行。如果以 OO 的观点来看这有点开玩笑了，会游泳和嘎嘎叫的可不止鸭子，它至少要来自禽类。可是别忘记了，鸭子可不会飞！所以它来自不来自禽类对于鸭子来说其实意义并不大！我们只关注它此刻能做什么，而不是关注它来自什么，如果一只猴子学会了游泳和嘎嘎叫，那么我们就用它来冒充鸭子有什么不可以吗？是的，“鸭类”就是这么任性，我们将这种面向能力的类统称为“鸭类”。在更多场合下你也可能看到“蛋糕模型”这个词汇，它们基本上指的是同一个意思。 那么怎么构造出一个鸭类呢？我们需要了解一个新的词汇叫 mix in（混入），以混入的角度，我们不需要考虑基类。坚守一个可能连 move 方法都是多余的基类真的是毫无意义。从混入的角度来看一个对象的本质，它只是一个专有的数据结构，比如身高，重量，颜色……等等，而所有的“方法”都是在构造的时候才添加进去，就好像工厂里组装台上的流水线。 还是以 Super Mario为例，其实通过不断地重构，现在我们已经获得了许许多多小的部件，比如 flyable, movable, jumping, swimable…和它们不同的实现，它们都被拆到了不同的“类”中，确切滴说，此时我们不再称它们为“类”，因为我们并不打算遵循OO的理念来使用它们，我们给他们一个新的称谓“特质”以有别于传统的“类”，在Scala语言中它有一个专有的关键词：trait。接下来我们是这样构建我们的Npc： 在以上代码中我们先是构建了一系列以行为为准则的“特质”，接下来当我们构建Mario 这个玩家的时候，我们既没有去实现它的行为也没有继承自父类，只是用一个关键词 with 来声明我们希望这个npc具有某种特定的 move 方式（在这里我们使用了特设泛型参数来指定我们需要一个专属于 Mario 的 Move 实例来提供支持），然后我们就可以在 play 里面直接使用这个方法了。这里的魔法还包括了那个奇怪的 “self: =>” 语法，这条语法被称为“自类型”，它的意识是“你认为你是什么你就是什么”。至于这个“什么”，就是冒号后指定的那一系列特质。在这里的意识是：我认为我是一个具有 “Mario走”和“Mario跳”特质的“Mario”（感觉好拗口）。此外我们还用到隐式来为将这些特质的实例注入到行为中去。关于隐式，这是另一个话题，在此我们不展开，现在我们只需要知道它为 Mario 对象提供了“依赖注入”就可以了。 让我们再来看一下它如何让我们具有构建不同的 Turtle 的能力 以上代码我们可以看到我们可以随意根据需要组合出只能飞的 Turtle，只能走的 Turtle 和即能飞也能走的 Turtle，随着我们提供的特质部件越来越多，我们甚至可以随时创造出能飞的、能游的……乌龟，并且这种能力不限于乌龟，我们也可以将这些部件用于不同的“妖怪”，使得它们也能具有不同的行为能力，甚至产生出组合妖怪，非常灵活。 从以上的例子我们可以看到当我们摆脱了继承的约束而实现了混入后，我们获得新对象的能力不仅没有削弱，反而更加强大，甚至我们还依然可以为方法提供依赖注入。这给予了我们更大的设计自由度。
信号量 Semaphore 数据类型，它允许通过 withPermit 方法在纤程之间进行同步，该方法可以安全地获取和释放许可证。信号量是基于 Ref[A] 数据类型的。 操作 例如，异步任务可以通过获取和释放具有给定数量许可的信号量来完成彼此的同步。当信号量中的许可值不足，获取操作无法执行时，该任务将在纤程队列中被置于挂起状态，直到有足够的许可值时被唤醒： （以上）二值信号量只是一种特殊的信号量。我们可以要求获取和释放任意指定数量的信号量： withPermit（及其对应的计数版本 withPermits）的保证是，无论任务是成功，失败还是被中断，许可证在被成功获取之后都会被释放。