内存泄漏

VisualVM 是Netbeans的profile子项目，已在JDK6.0 update 7 中自带(java启动时不需要特定参数，监控工具在bin/jvisualvm.exe)。 https://visualvm.dev.java.net/ 一、介绍 VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对 象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的). 从界面上看还是比较简洁的，左边是树形结构，自动显示当前本机所运行的Java程序，还可以添加远程的Java VM，其中括号里面的PID指的是进程ID。OverView界面显示VM启动参数以及该VM对应的一些属性。Monitor界面则是监控Java堆大小，Permgen大小，Classes和线程数量。jdk不同版本中界面会不太一致，如有的含cpu监控，有的则不含（jdk1.6.0_10未包含）。 官网上关于jvisualvm的用法介绍 http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html 作用：JVM和监控的应用程序运行在不同的服务器上，减轻应用程序的负担，特别是HeapDump的时候，应用常能够续负担很大。 VisualVM使用简单，几乎0配置，功能还是比较丰富的

1、内存溢出（out of memory） 　　是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。 2、内存泄露（ memory leak） 　　是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。 memory leak会最终会导致out of memory！ 在前面的ALLcations里面我们提到过 内存泄漏就是应该释放而没有释放的内存 。而内存泄漏分为两种： Leaked Memory 和 Abandoned Memory 。前面我们讲到了如何找到Abandoned Memory被遗忘的内存，现在我们研究的就是 Leaked Memory 。 以 发生的方式 来分类，内存泄漏可以分为4类： 常发性内存泄漏 。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 偶发性内存泄漏 。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 一次性内存泄漏 。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如

vue的自定义指令是一个比较容易引起内存泄漏的地方，原因就在于指令通常给元素绑定了事件，但是如果忘记了解绑，就会产生内存泄漏的问题。 　　看下面代码： directives: { scroll: { inserted (el, cb) { // 不是元素节点 || 未设置回调函数 if (el.nodeType !== 1 || !cb) return let direct = 'down' let rollHeight = 0 let getScrollEventTarget = (target) => { while (target.nodeType === 1 && target.tagName !== 'BODY' && el.tagName !== 'HTML') { var overflowY = getComputedStyle(target).overflowY if (overflowY === 'scroll' || overflowY === 'auto') { return target } target = target.parentNode } return window } let targetNode = getScrollEventTarget(el) let scrollListener = () => { if (targetNode

java垃圾回收器，开发者无需特意管理内存分配，降低了应用由于局部故障导致崩溃，同时防止未释放的内存把堆栈挤爆的可能，所以写出的代码更为安全。 但是，在java中仍存在很多容易导致内存泄漏的逻辑可能。如果不小心，则很容易浪费掉未释放的内存，最终导致内存用光的错误抛出OOM 内存泄漏 一般内存泄漏（traditional memory leak）：由忘记释放分配的内存导致的（Cursor忘记关闭等） 逻辑内存泄漏（logical memory leak）：当应用不再需要这个对象，但仍未释放该对象的所有引用 如果持有对象的强引用，垃圾回收器是无法在内存中回收这个对象 Android 中，最容易引发的内存泄漏为 Context，如Activity的Context，就包含了大量的内存引用，如View Hierarchies和其他资源。一旦泄漏Context，就意味着泄漏它指向的所有对象。android机器内存有限，太多的内存泄漏容易导致OOM Activity.onDestroy()被视为Activity生命的结束，程序上看来，它应该被销毁，或者Android系统需要回收这些内存（当内存不够时，android会回收看不见的activity） 如果Activity.onDestroy()执行完，堆栈中仍存在持有该activity的引用，垃圾回收器就无法把他标记成已回收的内存

避免 static Activity activity; 这样的代码，或在销毁时置为null 单例模式中Singleton的getInstance()方法时传入的context尽量传入context.getApplication（因为单例的生命周期为应用生命周期） 避免 static Views ;这样的代码，或在销毁时，置为null 内部类解决内存泄漏方式：1.内部类改为静态内部类，匿名内部类改为静态匿名内部类，，，，2.如果有强引用Activity中的属性，则将该属性的引用方式改为弱引用，，，，，3.在业务允许的情况下，在Activity执行onDestroy时，结束这些耗时任务 Handler内存泄漏解决方式：1.把Handler类放在单独的类文件中，或者使用静态内部类便可以避免泄漏，，，，，，2.如果想在Handler内部去调用所在的Activity，那么可在Handler内部使用弱引用的方式指向所在Activity，那么可以在handler内部使用弱引用的方式去指向所在Activity，使用static+weakReference的方式达到断开Handler与Activity之间存在引用关系的目的。，，，，，，3.在界面销毁时，释放handler资源（置null） 最主要原因为线程的生命周期不可控，若线程为Activity的内部类

引用 垃圾回收算法主要依赖引用的概念，例如一个对象如果有另外一个对象的访问权限，这里就叫做一个对象引用另外一个对象，不论这里是 显式还是隐式 回收机制 Js具有自动垃圾回收机制。垃圾收集器会按照固定的时间间隔周期性的执行。 第二种程序员自己释放 这个算最简单的回收算法，大致是某地对象当没有引用指向它的时候，也就是 零指向 ，这个对象就会被垃圾回收机制回收 let arr = [1,2,3] arr = null // [1,2,3]没有被引用，会被自动回收 标记清除 工作原理 ：当变量进入环境时，将这个变量标记为 “ 进入环境 ” 。当变量离开环境时，则将其标记为 “ 离开环境 ” 。标记 “ 离开环境 ” 的就回收内存。 工作流程 ： 垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记。 去掉环境中的变量以及被环境中的变量引用的变量的标记（闭包）。 依然被标记的会被视为准备删除的变量。 垃圾回收器完成内存清除工作，销毁那些带标记的值并回收他们所占用的内存空间。 引用计数 工作原理 ：跟踪记录每个值被引用的次数 工作流程 ： 声明了一个变量并将一个引用类型的值赋值给这个变量，这个引用类型值的引用次数就是 1 。 同一个值又被赋值给另一个变量，这个引用类型值的引用次数加 1. 当包含这个引用类型值的变量又被赋值成另一个值了，那么这个引用类型值的引用次数减 1. 当引用次数变成

程序会从根节点开始提问，其左右子树为疑犯名字或另外一个问题。先看数据结构： typedef struct node { char *question; struct node *no; struct node *yes; } node; 一个递归结构，内容很简单，一个char*指针，两个node指针。 节点的创建函数： node *create(char *question) { node *n = malloc(sizeof(node)); n->question = strdup(question); n->no = NULL; n->yes = NULL; return n; } 先分配空间，然后拷贝question字符串常量，两个node指针置空。 节点的销毁函数： void release(node *n) { if (n) { if (n->no) release(n->no); if (n->yes) release(n->yes); if (n->question) free(n->question); free(n); } } 从输入节点开始遍历，递归销毁其子树，释放n->question字符串，最后释放n。 一个通用的判断输入y/n的函数： int yes_no(char *question) { char answer[3]; printf("%s? (y/n

中高级阶段开发者出去面试，应该躲不开ThreadLocal相关问题，本文就常见问题做出一些解答，欢迎留言探讨。 ThreadLocal为java并发提供了一个新的思路， 它用来存储Thread的局部变量， 从而达到各个Thread之间的隔离运行。它被广泛应用于框架之间的用户资源隔离、事务隔离等。 但是用不好会导致内存泄漏， 本文重点用于对它的使用过程的疑难解答， 相信仔细阅读完后的朋友可以随心所欲的安全使用它。 内存泄漏原因探索 ThreadLocal操作不当会引发内存泄露，最主要的原因在于它的内部类ThreadLocalMap中的Entry的设计。 Entry继承了 WeakReference<ThreadLocal<?>> ，即Entry的key是弱引用，所以key'会在垃圾回收的时候被回收掉， 而key对应的value则不会被回收， 这样会导致一种现象：key为null，value有值。 key为空的话value是无效数据，久而久之，value累加就会导致内存泄漏。 static class ThreadLocalMap { static class Entry extends WeakReference<ThreadLocal<?>> { Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value =

今天给大家分享一些初中级的面试专题，比较适合在一些中小厂的开发者，跟随我一起来看看吧。 同样，关于下列PDF里所有的知识， 绝大部分有配套的视频.代码.源码.资料和笔记，对于我整理的核心PDF笔记感兴趣的 可以点击 关于我 联系我获取 (更多完整项目下载。未完待续。源码。图文知识后续上传github。) 初级面试专题（中小厂） 1、导致内存泄露的原因有哪些？ 内存泄露的根本原因：长生命周期的对象持有短生命周期的对象。短周期对象就无法及时释放。 静态内部类非静态内部类的区别(Handler 引起的内存泄漏。) 静态集合类引起内存泄露 单例模式引起的内存泄漏。 解决：Context是 ApplicationContext ，由于 ApplicationContext 的生命周期是和app一致的，不会导致内存泄漏 注册/反注册未成对使用引起的内存泄漏。 集合对象没有及时清理引起的内存泄漏。通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。 减少内存对象的占用 ArrayMap/SparseArray 代替 hashmap 避免在android里面使用 Enum 减少bitmap的内存占用 inSampleSize ：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。 decode format：解码格式

一、起 支付系统突然出现频繁的超时，查看error日志没有什么发现，凭经验去gc日志瞅一眼，有频繁的full gc，而且每两次gc，老年代会有80%的内存无法被回收，基本确认是系统出现内存泄漏，导致老年代空间被占满，频繁触发full gc,full gc 触发stop the word，导致业务接口超时。 二、承 2.1、dump内存数据 #netstat -tunlp|grep 端口号 #jmap -dump:live,file=dump.file pid 2.2、解析内存数据 #jhat -J-Xmx8192M dump.file 2.3、分析内存数据 查看实例个数前五的对象，可以看出第一名是第二名的实例个数的十几倍，大概率是class com.thoughtworks.xstream.core.util.CompositeClassLoader 对象造成的内存泄漏。 晚上搜资料，果然是。 我们支付系统在和微信第三方支付系统进行交互处理支付业务时，需要解析微信接口返回的XML数据，用到了xstream，而且每个请求都会新建一个xstream对象，xstream对象内部又会new CompositeClassLoader对象，Class.forName调用该Application ClassLoader，gc时xstream会被回收