gen_server中的数据在supervisor重启后还会保留吗？
我有一个启动许多 gen_server 的主管。每个 gen_server 都有大量的数据加载，这需要花费大量的时间。我想知道当错误发生时，存储在 gen_server 状态及其进程字典中的数据是否会保留以供下次启动，这样我就不需要再次初始化它们？
I have a supervisor which starts many gen_server. Each gen_server has a lot of data load which takes a lot of time. I want to know when error happens, will the data stored in gen_server's state and its process dict be kept for next start so I don't need to init them again?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Erlang 行为的当前状态不会保存在任何地方。你必须自己处理这个问题。
要么定期将状态保存在外部某个地方（在另一个进程中、ETS 表中、数据库中等），要么确保您的 init/1 函数足够智能和动态，能够重新创建启动时的状态（恢复现有文件，根据原始输入参数重新创建一些缓存等）
基本上，您必须定义哪些数据应该在崩溃中幸存下来以及如何保留或重新创建它。
The current state of an Erlang behavior is not saved anywhere. You would have to take care of that yourself.
Either you save the state regurlarly somewhere externally (in another process, in an ETS table, a database etc.) or you make sure that your
init/1function is sufficiently smart and dynamic to be able to recreate the state upon starting (recover existing files, recreate some cache based on the original input arguments etc.)Basically, you have to define what data should survive a crash and how to persist or recreate it.
如果您的应用程序中有任何数据需要持久保存应用程序崩溃，那么您需要将其与应用程序分离到数据库 (Mnesia) 或
ETS/DETS 表中。让 gen_server 状态包含live/temporary/transient信息，使其能够快速操作应用程序的瞬态状态。一旦你的 gen_server init/1 被调用，让它读取配置文件或数据库以获得开始状态。通常，当您的应用程序非常依赖服务器的最后状态时，每次收到操作 gen_server 状态的请求时，您都会从中提取信息并将其复制到持久存储中（并将此数据标记为先前已知的状态） ）。这使您的 init/1 函数能够始终检查最后/上一个状态或是否应该开始新状态。
If you have any data in your application that needs to persist a crash of your application, then you need to separate it from the application into a database (Mnesia) or
ETS/DETS tables. Let the gen_server state containlive/temporary/transientinfo that just allows it to quickly manipulate the transient state of your application.As soon as your gen_server init/1 is called, let it read a configuration file or Database to get a begin state. Usually, when your application depends so much on the last state of the server, each time a request comes in that manipulates the gen_server state, you extract info from it and copy it into a persistent storage (and label this data as the previous known state). This enables your init/1 function to always check for the last/previous state or whether it should begin a fresh state.