我有一个相当大的图表，里面充满了 PHP 内存中的循环引用。我正在序列化整个图表以将其存储在请求之间。它在 PHP5.3 上运行良好，但现在我升级到 PHP5.5 并且发生了一些奇怪的事情：
PHP / Apache 在序列化过程中突然崩溃/退出，并且 chrome 显示ERR_CONNECTION_RESETde PHP 日志中没有错误，调试模式下的 Apache 日志中也没有任何内容。
经过相当多的调试后，我注意到如果我将图表做得更小一点，它仍然可以工作。但是，如果我一点一点地重新打开数据，那么如果我重新引入它们，就会出现非常具体的失败点。如果我跳过该特定点并引入其他数据，我仍然可以继续。
不是内存问题
我设置了一个非常高的内存限制：memory_limit = 2048M，就在我介绍崩溃的数据之前，它memory_get_usage()给出了 26M 和memory_get_peak_usage()41M，所以还剩下很多。
不是时间问题
它可能与时间无关，因为它完全在超时设置内，并且当它崩溃时，它实际上崩溃的时间比完成最后一个工作序列化所需的时间要快。
太多的循环引用/循环？
我介绍的导致崩溃的数据在对象方面没有什么特别的。它们都是同一种 PHP 对象（为简单起见，节点和边）。此外，直接围绕我介绍的对象的关系并没有告诉我任何奇怪的事情。我正在考虑的一件事是，一旦引入了“有问题的”数据，序列化算法通过所有对象更改的方式，改变遍历路径并导致某些东西崩溃，因为......太深地需要？
其他一些上限？
我能想到的另一件事是我正在达到其他一些上限。因为问题是：一旦我发现一个“有问题”的数据，我无法重新打开而不会导致崩溃，如果我先关闭其他部分，我可以重新打开它。所以这似乎根本没有指向数据。但是哪个限制？我能够挤出的最大字符串长度是 5.517.365 个字符，根据mb_strlen($string, '8bit'). 但有时字符串大约有 400 万个字符，当我添加一点点时它会崩溃。这仍然可能意味着那一点点数据会导致图的一些更深/更大的部分更快地序列化，从而在内部达到相同的上限？
serialize() 是否使用缓冲区或 tmp 文件之类的东西，还是真的应该只使用“普通内存”？
知道我可能会遇到哪些其他界限吗？和/或哪些设置可以解决它？