JVM原理及内存溢出经典案列分析.ppt

,JVM原理及内存溢出经典案列分析,目录结构,目录,JVM基本概念JVM原理内存溢出现象内存溢出分析附录,JVM基本概念,JVM管理java中的内存java虚拟机自己去管理的，他不想C+需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。垃圾回收机制关键为了保证java内存不会溢出，java中有垃圾回收机制。System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象,JVM基本概念,内存溢出和泄露内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。,JVM原理,内存区划分,栈内存（Stack）：每个线程私有的。堆内存（Heap）：所有线程公用的。方法区（MethodArea）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。原生方法栈（NativeMethodStack）：主要用于JNI中的原生代码，平时很少涉及。,JVM原理,JVM分代总结：EdenSpace(heap)：内存最初从这个线程池分配给大部分对象。SurvivorSpace(heap)：用于保存在edenspace内存池中经过垃圾回收后没有被回收的对象。TenuredGeneration(heap)：用于保持已经在survivorspace内存池中存在了一段时间的对象。PermanentGeneration(non-heap):保存虚拟机自己的静态(refective)数据，例如类（class）和方法（method）对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的。CodeCache(non-heap):HotSpotJava虚拟机包括一个用于编译和保存本地代码（nativecode）的内存，叫做“代码缓存区”（codecache）。,JVM原理,JVM分代,JVM定义了两个代，年轻代（yonggeneration）（有时称为“nursery”托儿所）和老年代(oldgeneration)。年轻代包括“Edenspace（伊甸园）”和两个“survivorspaces”。虚拟内存初始化的时候会把所有对象都分配到Edenspace，并且大部分对象也会在该区域被释放。当进行minorGC的时候，VM会把剩下的没有释放的对象从Edenspace移动到其中一个survivorspaces当中。此外，VM也会把那些长期存活在survivorspaces里的对象移动到老生代的“tenured”space中。当tenuredgeneration被填满后，就会产生FullGC，FullGC会相对比较慢因为回收的内容包括了所有的live状态的对象。pemanetgeneration这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。,JVM原理,JVM收集方式一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minorcollection。另外一种称为majorcollectiont，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。,JVM原理,垃圾回收器Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存（Heap）有关。垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存区内执行一个局部的GC（也可以叫minorcollection）操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不FullGC要快很多。,JVM原理,垃圾回收器垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。JVM的垃圾回收器采用的是一种分代（generational）回收策略，用较高的频率对年轻的对象(younggeneration)进行扫描和回收，这种叫做minorcollection，而对老对象(oldgeneration)的检查回收频率要低很多，称为majorcollection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。,内存溢出现象,运行场景。1.用户并发测试，运行分钟，忽略思考时间。2.服务器内存分配JAVA_OPTS=-Xms2048m-Xmx2048m-Xss512k-XX:PermSize=128m3.分钟内达到内存分配最大值，从降到，后台抛出内存溢出错误查看tomcat下的catalina.out日志。Exceptioninthreadpool-1-thread-12java.lang.OutOfMemoryError:GCoverheadlimitexceeded这个内存溢出表示GC花了大量时间来回收无用对象时，回收的内存很小就抛出该异常。即回收效率不高最终导致内存溢出。,内存溢出现象,运行现象：jvisualvm监控消费者线程全是红颜色(在阻塞状态),内存溢出现象,运行现象：jconsole监控线程处于阻塞状态,内存溢出分析,业务场景：该mmsdk功能是记录行为日志，属于磁盘操作，当时为了减少主线程耗时，采用了生产者消费者模式，即主线程将需要记录的数据添加到队列中然后直接返回，消费者线程慢慢从队列中取出数据写入到磁盘中。根据上面的内存溢出信息可以知道是程序处理不过来，内存回收的速度跟不上增长的速度，也就是说回收的速度很低，gc回收效率极低，再根据该功能的业务场景，生产者消费者模式的特点-吞吐量优先，问题肯定出现在消费者这边，因为生产者50个用户一直在不停的生产，将数据放入到队列中，消费者20个一直在消费，理论上应该不会有什么问题，那是什么情况导致消费慢呢？通过监控程序运行很快就发现了问题所在，那就是消费者线程对锁的竞争非常激烈，90%的时间都在抢锁，那为什么抢锁这么厉害呢？肯定是所有线程都在抢一把锁，也就是说synchronized锁了一个共享变量。,内存溢出分析,代码分析：logs里面有30个BaseLoginfo对象，一个BaseLoginfo对象就是一条日志信息。每一个线程都要在这里循环30次，循环一次就要进入writeLog方法线程处于阻塞状态。,内存溢出分析,代码分析：进入eventService.writeLog()方法，如下所示：,这里可以看出来是把当前对象锁住了，而eventService总共就一个对象，所以20个线程都会抢这一个锁，那么为什么要锁这里呢？进入这个方法，里面是将日志信息写到文件中，20个线程，一个线程有30个对象每记录一个日志信息到文件都要获取锁和打开文件，写入文件，关闭文件，退出锁，瓶颈就在这里，锁竞争太激烈导致消费很慢，线程将所有时间都花在了抢锁上面,内存溢出分析,EclipseMemoryAnalyzer（MAT）：步骤：首先，对问题发生时刻的系统内存状态获取一个整体印象。第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。,内存溢出分析,内存镜像文件分析：内存镜像文件导出,jmap-F-dump:format=b,file=/home/middle/apache-tomcat-6.0.32/temp/heapdump-1349935865265.hprof14621,一块大内存占用了51M,内存溢出分析,内存镜像文件分析：53m的内存驻留在ThreadPoolExecutor对象中，,内存溢出分析,内存镜像文件分析：8个线程在作业，任务队列长度为512（代码里面设置的长度为512）,内存溢出分析,内存镜像文件分析：队列中保存了大量的UActionThread对象，内存达到53M,内存溢出分析,内存镜像文件分析：进一步查看，队列中保存了203个UActionThread对象，一个对象占用3.2k总共占用了53m,UActionThread对象,内存溢出分析,内存镜像文件分析：一个UActionThread对象中有多个RunTimeInfo对象(理论值是30个Run