Tagged: JVM

那我们就开一篇文章说一下这个问题，其实很easy的，无外乎三种情况。 linux的OOM killer杀死 JVM自身故障 jvm的OOM导致进程退出(很罕见，我至今没遇见过)

记一次隐藏很深的 JVM 线上惨案的分析、排查、解决！ JVM在反射代码执行的过程导致Full GC   ArrayList插入1000w条数据之后，我怀疑了jvm… 加个 -XX:+PrintGCDetails -XX:+PrintGCDateStamps，看下第一次是不是有Full GC   案例实战：每日上亿请求量的电商系统，JVM年轻代垃圾回收参数如何优化？   神奇的 perfma：一站式解决所有 JVM 疑难杂症！ JVM参数分析的链接地址：https://opts.console.perfma.com/   生产实践经验：线上系统的 JVM 内存是越大越好吗？ 所以很多人在用Elasticsearch的时候就是这样的一个问题，老是觉得ES读取速度慢，几个亿的数据写入ES，读取的时候要好几秒。那能不花费好几秒吗？你要是ES集群部署的时候，给JVM内存过大，给os cache留了几个GB的内存，导致几亿条数据大部分都在磁盘上，不在os cache里，最后读取的时候大量读磁盘，耗费个几秒钟是很正常的。 所以说，针对类似Kafka、Elasticsearch这种生产系统部署的时候，应该要给JVM比如6GB或者几个GB的内存就可以了。因为他们可能不需要耗费过大的内存空间，不依赖JVM内存管理数据，当然具体是设置多少，需要你精准的压测和优化。 但是对于这类系统，应该给os cache留出来足够的内存空间，比如32GB内存的机器，完全可以给os cache留出来20多G的内存空间，那么此时假设你这台机器总共就写入了20GB的数据，就可以全部驻留在os cache里了。然后后续在查询数据的时候，不就可以全部从os cache里读取数据了，完全依托内存来走，那你的性能必然是毫秒级的，不可能出现几秒钟才完成一个查询的情况。   为什么我们选择Java开发高频交易系统？...

1. 一、业务场景介绍 先简单说说线上生产系统的一个背景，因为仅仅是文章作为案例来讲，所以弱化大量的业务背景。 简单来说，这是一套分布式系统，系统A需要将一个非常核心以及关键的数据通过网络请求，传输给另外一个系统B。 所以这里其实就考虑到了一个问题，如果系统A刚刚将核心数据传递给了系统B，结果系统B莫名其妙宕机了，岂不是会导致数据丢失？

背景 最近网上出现一个美团面试题：“一个线程OOM后，其他线程还能运行吗？”。我看网上出现了很多不靠谱的答案。这道题其实很有难度，涉及的知识点有jvm内存分配、作用域、gc等，不是简单的是与否的问题。 由于题目中给出的OOM，java中OOM又分很多类型；比如：堆溢出（“java.lang.OutOfMemoryError: Java heap space”）、永久带溢出（“java.lang.OutOfMemoryError:Permgen space”）、不能创建线程（“java.lang.OutOfMemoryError:Unable to create new native thread”）等很多种情况。 本文主要是分析堆溢出对应用带来的影响。