你知道Chrome更新至104版后，竟导致Java服务内存泄漏了吗？

本文共计1006个文字，预计阅读时间需要5分钟。

前言：近期在工作中，遭遇了一次很有意义的内存泄漏，现将排查过程和思路记录下来，供大家参考和学习。如有不正确之处，欢迎指正。

起因：最近几天，处理大量客户托管业务，突然报告连接服务失败。

排查过程：

1.分析日志，发现服务端响应缓慢，疑似内存泄漏。

2.使用内存分析工具，定位到泄漏点。

3.优化代码，修复内存泄漏。

思路：

1.定期检查内存使用情况，及时发现异常。

2.使用内存分析工具，定位泄漏点。

3.优化代码，避免内存泄漏。

学习与参考：

1.深入了解内存管理机制。

2.学习内存分析工具的使用。

3.优化代码，提高程序性能。

前言

近期在工作中，遇到了一次很有意思的内存泄漏，把排查过程和思路记下来，供大家参考和学习，如有不正确的，欢迎指正。

起因

最近几天很多半托管客户，突然报连接服务失败，登上服务器后查看内存很高，为了让客户尽快恢复业务，运维同事第一时间选择了重启。

top图

重启后，内存肉眼可见的速度涨了上来，研发同事判断后，可能之后又需要重启，临时给客户部署了备用服务。（不管三七二十一先扩容）

冰山一角

• • 日志

• 日志

Too many open files 代表已经到了当前进程可以打开的最大文件数，第一时间选择了先加大当前进程打开的最大文件数，让后续的请求可以正常处理

echo - n "Max open files=85535:85535"

通过命令查看当前已经打开的文件数

lsof -p pid | wc -l
43326

正常的进程不可能打开这么多fd，所以应该存在连接泄漏

lsof - p pid | grep can't identify protocol

jstack打印当前的堆栈

jstack -l pid > pid.txt

找到当前堆栈中使用flags/#block-insecure-private-network-requests​​ 可以避免不

答：我测试104版本没效果

9、服务端如何兼容

答：服务器应检查是否存在Access-Control-Request-Private-Network: true标头。如果请求中存在此标头，则服务器应检查Origin标头和请求路径以及任何其他相关信息（例如Access-Control-Request-Headers）以确保请求是安全的。通常，您应该允许访问您控制下的单个源。

一旦您的服务器决定允许该请求，它应该响应204 No Content（或200 OK）必要的 CORS 标头和新的 PNA 标头。这些标头包括Access-Control-Allow-Origin和Access-Control-Allow-Private-Network: true，以及其他需要的标头。

响应示例

<pre class="prettyprint hljs groovy">HTTP/1.1 204 No Content
Access-Control-Allow-Origin: ​​foo.example​​ Access-Control-Allow-Private-Network: true</pre>

或者

<pre class="prettyprint hljs groovy">HTTP/1.1 200 No Content
Access-Control-Allow-Origin: ​​foo.example​​ Access-Control-Allow-Private-Network: true</pre>

10、服务端要不要兼容更新

答：我认为是有必要的，现在chrome发起options请求，你响应或者不响应都不会阻止后续的请求，但是如果他那天在自动更新，你如果未正常处理options请求，就不发送后续业务请求，

嗯。。。我已经联想到了一大部分程序员连夜加班修bug的场面了。

​按 Esc 退出