内存泄露

3 月，跳不动了？>>> 要点记录： 1、网页js、命令行工具， 快进快出的，即时内存泄露，无内存管理必要! 2、服务器端nodejs和其他正规语言一样存在内存泄露。 3、nodejs基于谷歌v8js引擎，速度很快，垃圾回收也是由v8维护的 4、通过查看源码可发现v8中用js使用内存的限制约为：64位-1.4G 32位 -0.7G。这是源于v8的垃圾回收机制的限制，可在node 后加 --max-old|new-space-size=xxx来改变内存限制 5、nodejs进程的内存占用：堆内内存+堆外内存=rss+swap+fs， 其中 v8申请和分配的为堆内内存，所有js实体都是通过堆来分配的。 process.memoryUsage() 可查看常驻内存rss，heapTotal总堆 内存，和已分配的堆内存heapUsed 非V8分配的内存为堆外内存，如 Buffer对象占据的内存，用在网络流和文件流中 os.totalmem os.freemem 可查看系统的总内存和可用 内存 6、v8的垃圾回收算法 统计学知识的应用，按对象存活时间将内存的垃圾回收进行不同的分代，对这些不同的分代分别实施不同的回收算法 v8中将内存主分为新生代 和 老生代 空间，前者存活时间短，后者较长或常驻 7、新生代中活对象较少，采用scavenge-cheney算法：将新生代一分为二，From ->To

因为工作用C#写的程序老是内存泄漏，在网上找了找资料后，发现了Windows自带的性能监视器Perfmon.exe可以辅助查看.NET程序的运行状况。今天研究了一番，下面的内容就是一些我认为比较重要需要记下来的东西~~~ 1）在开始菜单中输入perfmon就可以找到性能监视器（Perfmon.exe）了 2）进入性能监视器后，在左侧的抽屉菜单中找到“性能监视器” 可以发现，Perfmon中已经预设了一个计数器 \Processor Information(_Total)\% Processor Time 因为这个计数器和我们的目标没有太多关系，可以把它删除 3）添加下面几个计数器（含义部分采集自Perfmon自身说明） ①：Process下的Thread Count （注意选择对象实例-即要监视的具体进程） 含义：在这次处理中正在活动的线程数目。指令是在一台处理器中基本的执行单位，线程是指执行指令的对象。每个运行处理至少有一个线程。 ②：Process下的Handle Count（注意选择对象实例-即要监视的具体进程） 含义：由这个处理现在打开的句柄总数。这个数字等于这个处理中每个线程当前打开的句柄的总数。 ③：Process下的Private Bytes（注意选择对象实例-即要监视的具体进程） 含义：Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数。

JavaScript采用垃圾自动回收机制，运行时环境会自动清理不再使用的内存，因此javascript无需像C++等语言一样手动释放无用内存。 在这之前先说一下垃圾回收的两种方式： 引用计数 与 标记清除 。 引用计数 方式会为每个已分配内存单元设置计数器，当计数器减少到0的时候就意味着该单元无法再被引用，将会被清除。 有一个问题是，当存在循环引用时，内存单元的计数器将永远不为0，内存的释放会比较复杂（需要使用到弱引用 ）。 obj.val = obj2; obj2.val = obj; 标记清除 方 式维护一条链表，当变量进入scope时被加入这条链表，移出scope时被从链表剔除。当gc被激活时，首先为每个变量打上一个标记，然后清除存在于那条链表的变量的标记以及变量引用的成员的标记。最后，不再使用到的变量仍旧被gc标记着，将被释放，包括循环引用。 如果一段不再使用的内存未得到回收，将导致 内存泄露 ， 它将一直占据着内存而无法被利用，可能造成系统运行缓慢，浏览器崩溃等问题。 关于浏览器的javascript实现使用哪种回收机制，众说纷纭，感觉贵圈好乱。 我google了一下， http://www.ibm.com/developerworks/web/library/wa-memleak/?S_TACT=105AGX52&S_CMP=cn-a-wa

不少人认为 JAVA程序 ，因为有垃圾回收机制，应该没有内存泄露。 其实如果 我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它 ，当然该对象占用的内存就无法被使用 ，这就造成了内存泄露。 如果我们的 java 运行很久 , 而这种内存泄露不断的发生，最后就没内存可用了。当然 java 的内存泄漏和 C/C++ 是不一样的。如果 java 程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。 C/C++ 的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该 C/C++ 程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。 Android 的一个应用程序的内存泄露对别的应用程序影响不大。 为了能够使得 Android 应用程序安全且快速的运行， Android 的每个应用程序都会使用一个专有的 Dalvik 虚拟机实例来运行，它是由 Zygote 服务进程孵化出来的，也就是说 每个应用程序都是在属于自己的进程中运行的 。 Android 为不同类型的进程分配了不同的 内存使用上限 ，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会 被系统视为内存泄漏，从而被 kill 掉 ，这使得仅仅自己的进程被 kill 掉， 而

##This Handler class should be static or leaks might occur 有如下代码： public class MainActivity extends AppCompatActivity { private Handler handler = new Handler(){ //其他代码省略 }; //其他代码省略 } 会提示如下信息： Since this Handler is declared as an inner class, it may prevent the outer class from being garbage collected. If the Handler is using a Looper or MessageQueue for a thread other than the main thread, then there is no issue. If the Handler is using the Looper or MessageQueue of the main thread, you need to fix your Handler declaration, as follows: Declare the Handler as a static class; In the outer class

我们现在就来总结一下可能导致内存泄露的情况： 查询数据库而没有关闭Cursor 在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。 通常，在Activity中，我们可以调用 startManagingCursor 或直接使用 managedQuery 让Activity自动管理Cursor对象。 但需要注意的是，当Activity介绍后，Cursor将不再可用！ 若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。 除此之外，以下也是比较常见的Cursor不会被关闭的情况 ： try { Cursor c = queryCursor(); int a = c.getInt(1); ...... c.close(); } catch (Exception e) { } 虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。 所以，我们的代码应该以如下的方式编写： Cursor c = queryCursor(); try { int a = c.getInt(1); ...... } catch (Exception e) { }

什么是内存泄露？ Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），这仍然属于不可到达，同样会被GC回收。 Android中使用Handler造成内存泄露的原因 Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { mImageView.setImageBitmap(mBitmap); } } 上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来操作Activity中的View？）。而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。然而