如何解决Java 堆内存问题和 CPU 变高 突然的变化传统大量行源代码人工检查监控工具
我们使用 Java 作为中间件与 db 进行通信 - 但现在我们的 cpu 使用率提高了大约 400%。我们已经安装了 JVM 来监控问题 - 并发现了这个错误 - 你能建议我们改进吗? 我见过这些,
-
应用程序中有哪些对象占据了堆的大部分空间? -- 如何将其识别为 Java 的基础知识,是否有任何工具可以帮助我识别这一点?
-
这些对象被分配在源代码的哪些部分? -- 如何将其识别为 Java 的基础知识,是否有任何工具可以帮助我识别这一点?
o
rg.glassfish.jersey.server.ContainerException: java.lang.OutOfMemoryError:超出 GC 开销限制 ...httpserver.GrizzlyHttpContainer$ResponseWriter.rethrow(GrizzlyHttpContainer.java:318) ...httpserver.GrizzlyHttpContainer$ResponseWriter.failure(GrizzlyHttpContainer.java:300) ...lassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:486) org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:317) org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) org.glassfish.jersey.internal.Errors.process(Errors.java:315) org.glassfish.jersey.internal.Errors.process(Errors.java:297) org.glassfish.jersey.internal.Errors.process(Errors.java:267) ...ssfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:292) org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139) …ersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:375) org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:224) ...sh.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591) ...sfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571) java.lang.Thread.run(Thread.java:748) 由 java.lang.OutOfMemoryError 引起:超出 GC 开销限制
解决方法
这种错误很可怕,因为要找到真正的原因很复杂,需要中级java知识。
它永远不会伤害一点文档:
- https://www.baeldung.com/java-gc-overhead-limit-exceeded
- https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
突然的变化
如果是突然变化,这可能是原因。如果您对基础设施进行中间控制和监控,您应该能够检测何时此问题开始:
- 在新版本的 Java 应用程序发布之后
- 升级网络服务器后
- 操作系统升级后
- 在新版本的数据库之后(例如 oracle 11 > 12)
- 在数据库(内存、磁盘等)进行低级别更改后
- 用户数超出预期。可能是并发用户
如果之前的某些原因听起来您很熟悉,只需还原它并验证是否是资源(内存)耗尽的原因。
传统
在某些情况下,旧服务器或应用程序(几年前安装)可能是导致此类问题的原因:
- 临时文件不会被删除
- 磁盘达到最大值
- 已弃用的 Java 库
尝试升级网络服务器并重新部署您的应用程序。此外,如果您的应用程序不可知,请尝试部署到另一台服务器上。
大量行
有时[GC 开销限制超出]与此错误有关:
java.lang.OutOfMemoryError: Java heap space
这与具有大量行或大值的 ResultSet 相关。因此,它无法在 JVM 中为所需的内存分配堆空间。
如果是这种情况,请尝试:
stmt.setFetchSize
来源:
- http://benjchristensen.com/2008/05/27/mysql-jdbc-memory-usage-on-large-resultset/
- https://stackoverflow.com/a/15559710/3957754
- https://docs.oracle.com/cd/A87860_01/doc/java.817/a83724/resltse5.htm
- https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#setFetchSize(int)
源代码人工检查
此代码段能够复制您的错误:
Map<Integer,String> dataMap = new HashMap<>();
Random r = new Random();
while (true) {
dataMap.put(r.nextInt(),String.valueOf(r.nextInt()));
}
尝试逐级复习,以找到像代码段这样的块。
监控工具
有几种工具。它的使用并不那么容易。我建议您选择一个并使用一个简单的应用程序进行测试,例如:
- 摆动应用
- spring boot 最小rest api
- web 部署在 tomcat 中
如果您能够理解它的工作原理,请在您的实际应用程序中使用它。
可视化虚拟机
如您所见,此工具能够扫描您的所有类并获取相关元数据,例如:实时实例、内存等
来源:
- https://visualvm.github.io/
- https://docs.oracle.com/javase/8/docs/technotes/guides/visualvm/snapshots.html
Java 任务控制
Java Flight Recorder 和 JDK Mission Control 共同创建了一个完整的工具链,可以持续收集底层和详细的运行时信息,从而实现事后事件分析
来源:
- https://www.oracle.com/java/technologies/jdk-mission-control.html
- https://www.baeldung.com/java-flight-recorder-monitoring#3-visualize-data
Eclipse Profiler
在几乎所有的 Java Web 服务器中,remote debug 都是一个特性。
如果你可以配置它,你可以尝试eclipse配置文件。您将看到应用程序的所有类:
来源:
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。