因为附件服务重启的问题

生产的服务器出现以下现象：

1.API报503，

2.不停的重启

发现是OOM的错误。

作为经验法则，有几种常见的OOM情况。

堆内存溢出。如内存泄漏。

虚拟机栈和本地方法栈溢出。如有无限的递归方法。

JVM内存消耗超过容器限制。

从上面的截图中，可以看出

内存消耗接近100%。

CPU负载峰值少于5个，这应该是FULL-GC的结果。

GC指标相对健康，没有被频繁执行。

因为CPU负载不是很高，所以排除了虚拟机栈和本地方法栈溢出的情况。

package com.controllerimport org.apache.commons.io.FileUtils
import org.springframework.boot.actuate.management.HeapDumpWebEndpoint
import org.springframework.boot.actuate.management.ThreadDumpEndpoint
import org.springframework.core.io.Resource
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.ResponseBody
import org.springframework.web.bind.annotation.RestController
import java.io.IOException
import java.nio.charset.StandardCharsets
import javax.servlet.http.HttpServletResponse/*** The controller of Monitor****/
@RestController
@RequestMapping
class MonitorController(private val threadDumpEndpoint: ThreadDumpEndpoint?,private val heapDumpWebEndpoint: HeapDumpWebEndpoint?
) {@RequestMapping("jmap")@ResponseBody@Throws(IOException::class)fun jmap(response: HttpServletResponse?): String? {if (this.heapDumpWebEndpoint == null) {return "not existed"}val resource: Resource = this.heapDumpWebEndpoint.heapDump(true).getBody()val bytes: ByteArray = FileUtils.readFileToByteArray(resource.getFile())val delete: Boolean = resource.getFile().delete()return download(response!!, resource.getFilename()!!, bytes, delete.toString())}@GetMapping("jstack")@ResponseBodyfun jstack(response: HttpServletResponse): String? {if (threadDumpEndpoint == null) {return "not existed"}val threads = threadDumpEndpoint.textThreadDump()return download(response, "thread-dump.txt", threads.toByteArray(StandardCharsets.UTF_8), "")}private fun download(response: HttpServletResponse, fileName: String, bytes: ByteArray, value: String): String? {response.characterEncoding = "utf-8"response.contentType = "application/octet-stream"response.addHeader("Content-Length", bytes.size.toString())response.setHeader("Content-Disposition", "attachment; filename=$fileName")try {response.outputStream.use { outputStream ->outputStream.write(bytes)outputStream.flush()return value}} catch (exception: Exception) {return exception.message}}
}

检查JVM的启动配置。

由于堆内存溢出、虚拟机堆栈和本地方法堆栈溢出已经被排除，只剩下JVM内存消耗超过容器限制。让我们先检查一下附件中的JVM启动配置，以验证它。

JVM配置的屏幕截图

从上面的截图中可以看出。

GC使用G1，最大的垃圾年龄是5次（如果一个对象在交换5次后仍然存活，它将被复制到旧gen）。而GC暂停的最大毫秒数为80毫秒。

容器的最大内存限制是2G。

最小和最大的Heap Memory是一样的，都是1.6G左右。

Attachments占用的内存已经达到了容器上限的80%。