内存泄漏

原文地址： https://www.xingkongbj.com/blog/js/garbage-collection.html 垃圾回收--引用计数 将资源的被引用次数保存起来，当被引用次数变为零时就将其释放的过程。 会导致更多的内存泄漏，已不被采用。 导致的特殊内存泄漏 循环引用导致内存不能正常被回收 // 函数 a 执行完后，本来 x, y 对象都应该在垃圾回收阶段被回收， 可是由于存在循环引用，也不能被回收。 function a () { var x = {}; var y = {}; x.z = y; y.z = x; } a(); IE 6, 7 对DOM对象进行引用计数回收，这样简单的垃圾回收机制，非常容易出现循环引用问题导致内存不能被回收， 进行导致内存泄露等问题。 !function(){ // IE 6, 7 中下列代码会导致 btn 不能被回收 var btn = document.getElementsByTagName('button'); btn.onclick = function(){ console.log(btn.innerHTML); }; }(); 垃圾回收--标记清除 标记清除的方式需要对程序的对象进行两次扫描，第一次从根（Root）开始扫描，被根引用了的对象标记为不是垃圾，不是垃圾的对象引用的对象同样标记为不是垃圾，以此递归

内存泄漏 内存泄漏指的是在程序运行过程中申请了内存，但是在使用完成后没有及时释放的现象， 对于普通运行时间较短的程序来说可能问题不会那么明显，但是对于长时间运行的程序， 比如Web服务器，后台进程等就比较明显了，随着系统运行占用的内存会持续上升， 可能会因为占用内存过高而崩溃，或被系统杀掉。 Nginx&PHP-FPM 这里先简单说一下nginx+php-fpm模式的工作原理： nginx服务器fork出n个子进程（worker），php-fpm管理器fork出n个子进程。 当有用户请求，nginx的一个worker接收请求，并将请求抛到socket中。 php-fpm空闲的子进程监听到socket中有请求，接收并处理请求。 第三步涉及到php-fpm进程生命周期的东西。 一个php-fpm的生命周期大致是这样的： 模块初始化（MINIT） -> 模块激活（RINIT） -> 请求处理 -> 模块停用（RSHUTDOWN） -> 模块激活（RINIT） -> 请求处理 -> 模块停用（RSHUTDOWN） ……. -> 模块激活（RINIT） -> 请求处理 -> 模块停用（RSHUTDOWN） -> 模块关闭（MSHUTDOWN）。 在一个php-fpm进程的生命周期里，会有多次的模块激活（RINIT）-> 请求处理 -> 模块停用（RSHUTDOWN）的过程。 这个“请求处理

由于Java的特有属性，其垃圾回收机制的垃圾回收的时间不确定性，造成了Android的内存泄露问题，本文主要是说明一些Android中的内存泄露问题 内存泄漏概念 在C/C++中，堆内存的开辟和销毁是通过程序员通过 malloc/free 和 new/delete 去完成的，而在Java中，程序员只用开辟内存，而不用关心内存怎么去释放，这一切都交由Java的GC去完成 而内存泄漏问题，也就出在GC这里，如果一个对象已经不再被使用，这时候按理说应该回收其内存，但在这时候如果有其他使用的对象正在引用这个对象，那么GC就不能对其回收，从而继续保留在内存中，这样便产生了内存泄漏，究其本质，内存泄露的原因就是内存不在GC的掌控范围之内了 内存分区 内存可以人为的划分为几个区 静态区：存放静态数据和常量 方法区：存放代码 栈区：存放局部变量和基本数据类型，不会产生碎片，效率高，内存小 堆区：基本通过new关键字生成的对象都位于堆区，栈中只保留其索引位置 lrucache算法 按照使用频率决定回收顺序 在查阅 ListView 源代码的时候，发现其开辟的内存空间在UI层不可见的时候并没有被回收，而是被复用了，也就是 ConvertView 当需要加载大量数据或者图片的时候，往往是很耗费内存的，处理不当的话很容易直接造成OOM 那么，在内存和IO之间就需要一个平衡，也就是时间和空间的平衡性

一.内存泄漏 　　 内存泄漏指对象已经没有被应用程序 使用 ，但是垃圾回收器无法移除它们，因为还在被引用着。 　　出现内存泄漏的情况和防止 ： 长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。 　　1.当将HashMap，ArrayList，Vector等集合定义为静态的时候，他们的声明周期将会和应用程序一样长。他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。静态变量是全局的，GC不会回收。 　　2.事件监听器，当一个监听器在使用的时候被注册，但不再使用时被反注册，会出现内存泄漏。 　　3.如果一个类自己管理内存，常一些成员变量引用其他对象，初始化的时候需要置空。 　　4.JDK6中的 substirng() 方法容易导致内存泄漏。 　　5.各种连接 ： 　　比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。 　　 解决方法 ：通过工具查看泄漏对象到GC Roots的引用链，就能找到泄露对象是怎样的路径与GC Roots相连并导致垃圾回收器无法自动回收。 二.内存溢出 　

内存泄漏：由于疏忽或错误造成程序未能释放已经不再使用的内存。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费。 1、意外的全局变量 js对未声明变量会在全局最高对象上创建它的引用，（是以属性存在的，而不是变量），如果在游览器上就是window对象，如果在node环境下就是global;如果未声明的变量缓存大量的数据，它可能只有在页面被刷新或者被关闭的时候才会释放内存，这样就造成了内存意外泄漏。如下例子： function my() { name="my name is tokey" } my() console.log(window) 在控制台可以看到 还有通过this创建意外的全局变量 function my() { this.name="my name is tokey" } my() console.log(window.name)　　//my name is tokey 此时的this指向的并不是undefined而是全局对象window 针对上面类型的内存泄漏我们在平时一定要声明变量，不要有全局直接引用。（在JavaScript文件中添加 'use strict' ，开启严格模式，可以有效地避免上述问题。） 2、console.log 作为前端平时使用console

上周从周五开始疯狂修仙，累的一批。 周日正美滋滋的睡着回笼觉，准备补回觉，突然被一个电话打过来去公司查软件内存泄漏问题（连续查了两天）。 当时软件的情况是24 小时内存增加600mb内存，而验收标准是连续跑24 * 7小时，所以对于32位程序来说将达到4.2GB 会出现内存无法分配的情况（超出32位指针访问地址的上限）。 分析问题使用的方法有两种： 一、第一阶段 目测法： 通过注释部分模块，加速运行的方法，查看任务管理器，有无内存泄漏。 时间：1天 结果：不能查找出，感觉很多模块都没有泄露，又都有略微增长。 二、第二阶段 时间：1天 工具法：使用内存泄漏检测工具 使用了的工具有：VLD（Visual Leak Detector），tMemoryMonitor，WinDbg 其中WinDbg是在运行中抓取前后两次内存数据，然后对内存数据进行对比的方式，对抓取的时间节点很考究。 VLD和tMemoryMonitor都是运行结束后再进行生成泄漏报告的方式 VLD需要修改源代码，增加头文件(可以支持Debug版和Release版)，会大大降低程序运行的速度。 tMemoryMonitor只支持Release版，且对性能影响较小 三、工具使用方法 1、tMemoryMonitor使用最简单，下载地址： http://wetest.qq.com/cloud/index.php/index

ThreadLocal的原理：每个Thread内部维护着一个ThreadLocalMap，它是一个Map。这个映射表的Key是一个 弱引用 ，其实就是ThreadLocal本身，Value是真正存的线程变量Object。 ThreadLocal在ThreadLocalMap中是以一个弱引用身份被Entry中的Key引用的，因此如果ThreadLocal没有外部强引用来引用它，那么ThreadLocal会在下次JVM垃圾收集时被回收。这个时候就会出现Entry中Key已经被回收，出现一个null Key的情况，外部读取ThreadLocalMap中的元素是无法通过null Key来找到Value的。因此如果当前线程的生命周期很长，一直存在，那么其内部的ThreadLocalMap对象也一直生存下来，这些null key就存在一条强引用链的关系一直存在：Thread --> ThreadLocalMap-->Entry-->Value，这条强引用链会导致Entry不会回收，Value也不会回收，但Entry中的Key却已经被回收的情况，造成内存泄漏。 但是JVM团队已经考虑到这样的情况，并做了一些措施来保证ThreadLocal尽量不会内存泄漏：在ThreadLocal的get()、set()、remove(

内存泄漏概念：内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。 一、单例模式使用Activity作为Context 单例模式中应该避免使用Activity作为传入的Context，否则，单例模式会持有这个Activity的引用，导致它无法释放，造成内存泄漏。应该使用ApplicationContext作为Context传入。如果一定要使用Activity的话，要使用弱引用WeakReference。 二、未关闭资源或者没有反注册 BroadcastReceiver，File，Cursor，IO流等资源在 Activity 的onDestroy必须unregister 或者 close ，否则这个 Activity 类会被 system 强引用，不会被内存回收。关闭的语句必须在finally中进行关闭，否则有可能因为异常未关闭资源，致使activity泄漏。 三、Handler造成内存泄漏 只要 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有。特别是handler执行延迟任务。所以，Handler 的使用要尤为小心，否则将很容易导致内存泄露的发生。 public

ThreadLocal为Java并发提供了一个新的思路， 它用来存储Thread的局部变量， 从而达到各个Thread之间的隔离运行。它被广泛应用于框架之间的用户资源隔离、事务隔离等。 但是用不好会导致内存泄漏， 本文重点用于对它的使用过程的疑难解答， 相信仔细阅读完后的朋友可以随心所欲的安全使用它。 一、内存泄漏原因探索 ThreadLocal操作不当会引发内存泄露，最主要的原因在于它的内部类ThreadLocalMap中的Entry的设计。 Entry继承了WeakReference<ThreadLocal<?>>，即Entry的key是弱引用，所以key’会在垃圾回收的时候被回收掉， 而key对应的value则不会被回收， 这样会导致一种现象：key为null，value有值。 key为空的话value是无效数据，久而久之，value累加就会导致内存泄漏。 二、怎么解决这个内存泄漏问题 每次使用完ThreadLocal都调用它的remove()方法清除数据。因为它的remove方法会主动将当前的key和value(Entry)进行清除。 e.clear()用于清除Entry的key，它调用的是WeakReference中的方法:this.referent = null expungeStaleEntry(i)用于清除Entry对应的value， 这个后面会详细讲。 三

昨天看到了select timeAfter可以很方便的实现接口超时，今天再针对timer使用时需要注意的几个陷阱总结一下。 go里面定时任务是在时间推里面，定时任务到期之前，是不会被gc清理掉的。这样如果短时间内创建大量定时任务，就会造成内存泄漏。 for { timerC := time . After ( 2 * time . Second ) //timerC 每次都是重新创建的，什么意思呢？简单说来，当 select 成功监听 ch 并进入它的处理分支，下次循环 timerC 重新创建了，时间肯定就重置了。 select { //如果有多个 case 都可以运行，select 会随机公平选择出一个执行。其余的则不会执行 case num := <- ch : fmt . Println ( "get num is" , num ) case <- timerC : //等价于 case <-time.After(2 * time.Second) fmt . Println ( "time's up!!!" ) //done<-true } } 这样的写法在for循环里用time.After 典型的内存泄漏，time.After 每次会产生一个新的定时器。解决办法就是采用timer代替，每次重置timer。 idleDuration := 2 * time . Second