akka-stream docs 中有这样一条说明如下：
... 可重用的流描述不能绑定到“实时”资源，任何与此类资源的连接或分配都必须推迟到实现时间。 “实时”资源的示例是已经存在的 TCP 连接、多播发布者等； …
我有几个关于笔记的问题：
Thread？ ActorFlowMaterializer 使用的ActorSystem 中存在一个ActorRef 怎么样？ PushPullStage 的构造函数中分配它是否安全，但在FlowGraph 的创建函数中分配它不安全？【问题讨论】：
标签： java scala akka akka-stream
如果我们考虑 web 服务、RMI 连接或任何其他通信协议，这里的问题是一个常见问题。始终建议共享“原始”值然后引用，因为编组/解组或序列化/反序列化总是令人头疼。还要考虑相互交流的不同类型的环境。分享坚实的价值观是解决沟通问题的安全方式。
Akka 本身就是“微服务”相互通信参与者的一个很好的例子。当我阅读 Akka 的文档时，一个好词很好地定义了 Akka 演员。 Actor 就像邮箱客户端，您可以认为每个客户端都有一个邮箱。当您传递一个变量时，就像您收到一封新电子邮件一样。
长话短说，避免共享“依赖”对象，这些对象在从其他参与者读取之前可能会失效。此外，如果您的系统动态命名 actorRefs，请避免通过其引用调用它们。
“物化”在 akka-streams 的文档中进行了解释。
物化过程可以参数化，例如使用有关连接地址和端口信息的特定信息来实例化处理 TCP 连接数据的蓝图。此外，物化通常会创建特定对象，这些对象在处理引擎运行后可用于与处理引擎进行交互，例如用于关闭它或用于提取指标。这意味着物化函数从外部获取一组参数并产生一组结果。组合性要求这两个集合不能交互，因为这会建立一个隐蔽的通道，不同的部分可以通过该通道进行通信，从而导致初始化顺序问题和难以理解的运行时故障。
所以使用参数而不是传递“连接”本身。
推迟实时资源并不是什么大问题。这意味着如果您为所有系统使用一个连接，您应该始终保持它处于活动状态。或者当您在actor-1 中创建一个事务并将其发送给actor-2 时，您不应该在actor-1 中终止事务，直到actor-2 完成其事务工作。
那你怎么理解？然后你使用“Future”和“offer()”。
希望我能理解你的问题并希望我能表达自己。
【讨论】：