有返回大型JSON数据的REST-API示例结果：
{
"arrayA":[
{
"data1":"data",
"data2":"data"
},..
],
"arrayB":[
{
"data1":"data"
},..
]
}
"arrayA"；可能的记录只有0到100个记录；阵列B"；可能有100万到1000万的记录它使我的java应用程序内存不足。我的问题是如何处理这个案子。
这里有不同的关注点，IMO认为这个问题太宽泛了，因为最佳解决方案可能取决于实际用例。
你说，你有一个REST API，你想"保护"服务器免受内存不足错误，我明白了。
然而，假设您找到了修复服务器上OOM错误的方法，那么什么样的客户端会希望同时查看数千万个对象？如果是浏览器，真的需要吗？客户端的JSON处理需要多长时间？应用程序的客户端不会变得太慢，客户端会开始抱怨吗？我相信你说得对。
因此，第一种方法是"重新思考"为什么你需要如此大的回应。在这种情况下，最好的解决方案可能是重构和更改客户端-服务器通信的逻辑
现在，另一种可能的情况是，您有一个"集成"——某种服务器到服务器的通信。
在这种情况下，一次添加整个json响应甚至进行流传输都没有意义。例如，如果你在云中运行，你可能想把这个巨大的json字符串添加到某个文件中，并上传到S3，然后提供一个链接(因为S3可以处理这样的文件(。当然，在非AWS环境中还有其他选择。
作为一个"精简"的想法，您可以获得请求，在文件系统上创建临时文件，将数据分块写入其中，然后将"FileResource"返回给客户端。逐块工作将确保java应用程序的内存消耗很低。基本上，这相当于下载动态生成的文件。关闭流时，您可能希望删除该文件。
如果您有某种"获取堆转储"或任何通用功能中的数据转储，这将是最好的工作方式。