设为首页收藏本站
开启辅助访问

在路上

 找回密码
 立即注册
在路上 › 站点首页 ›学习 › 查看内容

JVM源码分析之堆外内存完全解读

2017-2-16 13:16| 发布者: zhangjf| 查看: 1106| 评论: 0

摘要: 原文 http://lovestblog.cn/blog/2015/05/12/direct-buffer/ 概述 广义的堆外内存 说到堆外内存，那大家肯定想到堆内内存，这也是我们大家接触最多的，我们在jvm参数里通常设置-Xmx来指定我们的堆的最大值，不 ...
原文 http://lovestblog.cn/blog/2015/05/12/direct-buffer/ 概述 广义的堆外内存

说到堆外内存，那大家肯定想到堆内内存，这也是我们大家接触最多的，我们在jvm参数里通常设置-Xmx来指定我们的堆的最大值，不过这还不是我们理解的Java堆，-Xmx的值是新生代和老生代的和的最大值，我们在jvm参数里通常还会加一个参数-XX:MaxPermSize来指定持久代的最大值，那么我们认识的Java堆的最大值其实是-Xmx和-XX:MaxPermSize的总和，在分代算法下，新生代，老生代和持久代是连续的虚拟地址，因为它们是一起分配的，那么剩下的都可以认为是堆外内存(广义的)了，这些包括了jvm本身在运行过程中分配的内存，codecache，jni里分配的内存，DirectByteBuffer分配的内存等等

狭义的堆外内存

而作为java开发者，我们常说的堆外内存溢出了，其实是狭义的堆外内存，这个主要是指java.nio.DirectByteBuffer在创建的时候分配内存，我们这篇文章里也主要是讲狭义的堆外内存，因为它和我们平时碰到的问题比较密切

JDK/JVM里DirectByteBuffer的实现

DirectByteBuffer通常用在通信过程中做缓冲池，在mina，netty等nio框架中屡见不鲜，先来看看JDK里的实现：

  1. DirectByteBuffer(int cap) { // package-private
  3. super(-1, 0, cap, cap);
  4. boolean pa = VM.isDirectMemoryPageAligned();
  5. int ps = Bits.pageSize();
  6. long size = Math.max(1L, (long)cap + (pa ? ps : 0));
  7. Bits.reserveMemory(size, cap);
  9. long base = 0;
  10. try {
  11. base = unsafe.allocateMemory(size);
  12. } catch (OutOfMemoryError x) {
  13. Bits.unreserveMemory(size, cap);
  14. throw x;
  15. }
  16. unsafe.setMemory(base, size, (byte) 0);
  17. if (pa && (base % ps != 0)) {
  18. // Round up to page boundary
  19. address = base + ps - (base & (ps - 1));
  20. } else {
  21. address = base;
  22. }
  23. cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
  24. att = null;
  28. }
复制代码

通过上面的构造函数我们知道，真正的内存分配是使用的Bits.reserveMemory方法

  1. static void reserveMemory(long size, int cap) {
  2. synchronized (Bits.class) {
  3. if (!memoryLimitSet && VM.isBooted()) {
  4. maxMemory = VM.maxDirectMemory();
  5. memoryLimitSet = true;
  6. }
  7. // -XX:MaxDirectMemorySize limits the total capacity rather than the
  8. // actual memory usage, which will differ when buffers are page
  9. // aligned.
  10. if (cap <= maxMemory - totalCapacity) {
  11. reservedMemory += size;
  12. totalCapacity += cap;
  13. count++;
  14. return;
  15. }
  16. }
  18. System.gc();
  19. try {
  20. Thread.sleep(100);
  21. } catch (InterruptedException x) {
  22. // Restore interrupt status
  23. Thread.currentThread().interrupt();
  24. }
  25. synchronized (Bits.class) {
  26. if (totalCapacity + cap > maxMemory)
  27. throw new OutOfMemoryError("Direct buffer memory");
  28. reservedMemory += size;
  29. totalCapacity += cap;
  30. count++;
  31. }
  33. }
复制代码

通过上面的代码我们知道可以通过-XX:MaxDirectMemorySize来指定最大的堆外内存，那么我们首先引入两个问题

堆外内存默认是多大 为什么要主动调用System.gc() 堆外内存默认是多大

如果我们没有通过-XX:MaxDirectMemorySize来指定最大的堆外内存，那么默认的最大堆外内存是多少呢，我们还是通过代码来分析

上面的代码里我们看到调用了sun.misc.VM.maxDirectMemory()

  1. private static long directMemory = 64 * 1024 * 1024;
  3. // Returns the maximum amount of allocatable direct buffer memory.
  4. // The directMemory variable is initialized during system initialization
  5. // in the saveAndRemoveProperties method.
  6. //
  7. public static long maxDirectMemory() {
  8. return directMemory;
  9. }
复制代码

看到上面的代码之后是不是误以为默认的最大值是64M？其实不是的，说到这个值得从java.lang.System这个类的初始化说起

  1. /**
  2. * Initialize the system class. Called after thread initialization.
  3. */
  4. private static void initializeSystemClass() {
  6. // VM might invoke JNU_NewStringPlatform() to set those encoding
  7. // sensitive properties (user.home, user.name, boot.class.path, etc.)
  8. // during "props" initialization, in which it may need access, via
  9. // System.getProperty(), to the related system encoding property that
  10. // have been initialized (put into "props") at early stage of the
  11. // initialization. So make sure the "props" is available at the
  12. // very beginning of the initialization and all system properties to
  13. // be put into it directly.
  14. props = new Properties();
  15. initProperties(props); // initialized by the VM
  17. // There are certain system configurations that may be controlled by
  18. // VM options such as the maximum amount of direct memory and
  19. // Integer cache size used to support the object identity semantics
  20. // of autoboxing. Typically, the library will obtain these values
  21. // from the properties set by the VM. If the properties are for
  22. // internal implementation use only, these properties should be
  23. // removed from the system properties.
  24. //
  25. // See java.lang.Integer.IntegerCache and the
  26. // sun.misc.VM.saveAndRemoveProperties method for example.
  27. //
  28. // Save a private copy of the system properties object that
  29. // can only be accessed by the internal implementation. Remove
  30. // certain system properties that are not intended for public access.
  31. sun.misc.VM.saveAndRemoveProperties(props);
  33. ......
  35. sun.misc.VM.booted();
  36. }
复制代码

上面这个方法在jvm启动的时候对System这个类做初始化的时候执行的，因此执行时间非常早，我们看到里面调用了sun.misc.VM.saveAndRemoveProperties(props):

  1. public static void saveAndRemoveProperties(Properties props) {
  2. if (booted)
  3. throw new IllegalStateException("System initialization has completed");
  5. savedProps.putAll(props);
  7. // Set the maximum amount of direct memory. This value is controlled
  8. // by the vm option -XX:MaxDirectMemorySize=<size>.
  9. // The maximum amount of allocatable direct buffer memory (in bytes)
  10. // from the system property sun.nio.MaxDirectMemorySize set by the VM.
  11. // The system property will be removed.
  12. String s = (String)props.remove("sun.nio.MaxDirectMemorySize");
  13. if (s != null) {
  14. if (s.equals("-1")) {
  15. // -XX:MaxDirectMemorySize not given, take default
  16. directMemory = Runtime.getRuntime().maxMemory();
  17. } else {
  18. long l = Long.parseLong(s);
  19. if (l > -1)
  20. directMemory = l;
  21. }
  22. }
  24. // Check if direct buffers should be page aligned
  25. s = (String)props.remove("sun.nio.PageAlignDirectMemory");
  26. if ("true".equals(s))
  27. pageAlignDirectMemory = true;
  29. // Set a boolean to determine whether ClassLoader.loadClass accepts
  30. // array syntax. This value is controlled by the system property
  31. // "sun.lang.ClassLoader.allowArraySyntax".
  32. s = props.getProperty("sun.lang.ClassLoader.allowArraySyntax");
  33. allowArraySyntax = (s == null
  34. ? defaultAllowArraySyntax
  35. : Boolean.parseBoolean(s));
  37. // Remove other private system properties
  38. // used by java.lang.Integer.IntegerCache
  39. props.remove("java.lang.Integer.IntegerCache.high");
  41. // used by java.util.zip.ZipFile
  42. props.remove("sun.zip.disableMemoryMapping");
  44. // used by sun.launcher.LauncherHelper
  45. props.remove("sun.java.launcher.diag");
  46. }
复制代码

如果我们通过-Dsun.nio.MaxDirectMemorySize指定了这个属性，只要它不等于-1，那效果和加了-XX:MaxDirectMemorySize一样的，如果两个参数都没指定，那么最大堆外内存的值来自于directMemory = Runtime.getRuntime().maxMemory()，这是一个native方法

  1. JNIEXPORT jlong JNICALL
  2. Java_java_lang_Runtime_maxMemory(JNIEnv *env, jobject this)
  3. {
  4. return JVM_MaxMemory();
  5. }
  7. JVM_ENTRY_NO_ENV(jlong, JVM_MaxMemory(void))
  8. JVMWrapper("JVM_MaxMemory");
  9. size_t n = Universe::heap()->max_capacity();
  10. return convert_size_t_to_jlong(n);
  11. JVM_END
复制代码

其中在我们使用CMS GC的情况下的实现如下，其实是新生代的最大值-一个survivor的大小+老生代的最大值，也就是我们设置的-Xmx的值里除去一个survivor的大小就是默认的堆外内存的大小了

  1. size_t GenCollectedHeap::max_capacity() const {
  2. size_t res = 0;
  3. for (int i = 0; i < _n_gens; i++) {
  4. res += _gens[i]->max_capacity();
  5. }
  6. return res;
  7. }
  9. size_t DefNewGeneration::max_capacity() const {
  10. const size_t alignment = GenCollectedHeap::heap()->collector_policy()->min_alignment();
  11. const size_t reserved_bytes = reserved().byte_size();
  12. return reserved_bytes - compute_survivor_size(reserved_bytes, alignment);
  13. }
  15. size_t Generation::max_capacity() const {
  16. return reserved().byte_size();
  17. }
复制代码

为什么要主动调用System.gc

既然要调用System.gc，那肯定是想通过触发一次gc操作来回收堆外内存，不过我想先说的是堆外内存不会对gc造成什么影响(这里的 System.gc除外)，但是堆外内存的回收其实依赖于我们的gc机制，首先我们要知道在java层面和我们在堆外分配的这块内存关联的只有与之关联的 DirectByteBuffer对象了，它记录了这块内存的基地址以及大小，那么既然和gc也有关，那就是gc能通过操作 DirectByteBuffer对象来间接操作对应的堆外内存了。DirectByteBuffer对象在创建的时候关联了一个 PhantomReference，说到PhantomReference它其实主要是用来跟踪对象何时被回收的，它不能影响gc决策，但是gc过程中如果发现某个对象除了只有PhantomReference引用它之外，并没有其他的地方引用它了，那将会把这个引用放到 java.lang.ref.Reference.pending队列里，在gc完毕的时候通知ReferenceHandler这个守护线程去执行一些后置处理，而DirectByteBuffer关联的PhantomReference是PhantomReference的一个子类，在最终的处理里会通过Unsafe的free接口来释放DirectByteBuffer对应的堆外内存块

JDK里ReferenceHandler的实现：

  1. private static class ReferenceHandler extends Thread {
  3. ReferenceHandler(ThreadGroup g, String name) {
  4. super(g, name);
  5. }
  7. public void run() {
  8. for (;;) {
  10. Reference r;
  11. synchronized (lock) {
  12. if (pending != null) {
  13. r = pending;
  14. Reference rn = r.next;
  15. pending = (rn == r) ? null : rn;
  16. r.next = r;
  17. } else {
  18. try {
  19. lock.wait();
  20. } catch (InterruptedException x) { }
  21. continue;
  22. }
  23. }
  25. // Fast path for cleaners
  26. if (r instanceof Cleaner) {
  27. ((Cleaner)r).clean();
  28. continue;
  29. }
  31. ReferenceQueue q = r.queue;
  32. if (q != ReferenceQueue.NULL) q.enqueue(r);
  33. }
  34. }
  35. }
复制代码

可见如果pending为空的时候，会通过lock.wait()一直等在那里，其中唤醒的动作是在jvm里做的，当gc完成之后会调用如下的方法VM_GC_Operation::doit_epilogue()，在方法末尾会调用lock的notify操作，至于pending队列什么时候将引用放进去的，其实是在gc的引用处理逻辑中放进去的，针对引用的处理后面可以专门写篇文章来介绍

  1. void VM_GC_Operation::doit_epilogue() {
  2. assert(Thread::current()->is_Java_thread(), "just checking");
  3. // Release the Heap_lock first.
  4. SharedHeap* sh = SharedHeap::heap();
  5. if (sh != NULL) sh->_thread_holds_heap_lock_for_gc = false;
  6. Heap_lock->unlock();
  7. release_and_notify_pending_list_lock();
  8. }
  10. void VM_GC_Operation::release_and_notify_pending_list_lock() {
  11. instanceRefKlass::release_and_notify_pending_list_lock(&_pending_list_basic_lock);
  12. }
复制代码

对于System.gc的实现，之前写了一篇文章来重点介绍， JVM源码分析之SystemGC完全解读 ，它会对新生代的老生代都会进行内存回收，这样会比较彻底地回收DirectByteBuffer对象以及他们关联的堆外内存，我们dump内存发现 DirectByteBuffer对象本身其实是很小的，但是它后面可能关联了一个非常大的堆外内存，因此我们通常称之为『冰山对象』，我们做ygc的时候会将新生代里的不可达的DirectByteBuffer对象及其堆外内存回收了，但是无法对old里的DirectByteBuffer对象及其堆外内存进行回收，这也是我们通常碰到的最大的问题，如果有大量的DirectByteBuffer对象移到了old，但是又一直没有做cms gc或者full gc，而只进行ygc，那么我们的物理内存可能被慢慢耗光，但是我们还不知道发生了什么，因为heap明明剩余的内存还很多(前提是我们禁用了 System.gc)。

为什么要使用堆外内存

DirectByteBuffer在创建的时候会通过Unsafe的native方法来直接使用malloc分配一块内存，这块内存是heap 之外的，那么自然也不会对gc造成什么影响(System.gc除外)，因为gc耗时的操作主要是操作heap之内的对象，对这块内存的操作也是直接通过 Unsafe的native方法来操作的，相当于DirectByteBuffer仅仅是一个壳，还有我们通信过程中如果数据是在Heap里的，最终也还是会copy一份到堆外，然后再进行发送，所以为什么不直接使用堆外内存呢。对于需要频繁操作的内存，并且仅仅是临时存在一会的，都建议使用堆外内存，并且做成缓冲池，不断循环利用这块内存。

为什么不能大面积使用堆外内存

如果我们大面积使用堆外内存并且没有限制，那迟早会导致内存溢出，毕竟程序是跑在一台资源受限的机器上，因为这块内存的回收不是你直接能控制的，当然你可以通过别的一些途径，比如反射，直接使用Unsafe接口等，但是这些务必给你带来了一些烦恼，Java与生俱来的优势被你完全抛弃了—开发不需要关注内存的回收，由gc算法自动去实现。另外上面的gc机制与堆外内存的关系也说了，如果一直触发不了cms gc或者full gc，那么后果可能很严重。

收藏 邀请
上一篇：泛型方法的反模式下一篇：用Java语言编写的印刷体科技文档识别系统：MathOCR

最新评论

相关分类

小黑屋|在路上 ( 蜀ICP备15035742号-1 )  

;

GMT+8, 2025-5-6 13:17

Copyright 2015-2025 djqfx

返回顶部