精华内容
下载资源
问答
  • PHP内存泄漏问题解析

    万次阅读 2016-12-18 20:37:49
    内存泄漏内存泄漏指的是在程序运行过程中申请了内存,但是在使用完成后没有及时释放的现象, 对于普通运行时间较短的程序来说可能问题不会那么明显,但是对于长时间运行的程序, 比如Web服务器,后台进程等就比较...

    内存泄漏

    内存泄漏指的是在程序运行过程中申请了内存,但是在使用完成后没有及时释放的现象, 对于普通运行时间较短的程序来说可能问题不会那么明显,但是对于长时间运行的程序, 比如Web服务器,后台进程等就比较明显了,随着系统运行占用的内存会持续上升, 可能会因为占用内存过高而崩溃,或被系统杀掉

    PHP的内存泄漏

    PHP属于高级语言,语言级别并没有内存的概念,在使用过程中完全不需要主动申请或释放内存, 所以在PHP用户代码级别也就不存在内存泄漏的概念了。

    但毕竟PHP是使用C编写的解释器,而C语言的程序是可能出现内存泄漏问题,所以本质上还是一样的,那么可以这么说:如果你的PHP程序内存泄漏了,会有三种可能:

    1. 首先肯能是自己的代码有问题,比如没有及时释放大内存的变量等。
    2. 很多公司都会有自己的PHP扩展,而扩展通常也使用C/C++来编写,这样扩展本身也可能会因为内存不正确释放而导致内存泄漏。
    3. 有些扩展是对第三方库的一种包裹, 比如PHP的sqlite数据库操作接口主要是在libsqlite之上进行了封装,所以如果 libsqlite本身有内存泄漏的话,那也可能会带来问题。

    PHP-CGI

    根据官方的介绍,php-cgi不存在内存泄漏,每个请求完成后php-cgi会回收内存,但是不会释放给操作系统,这样就会导致大量内存被php-cgi占用。(这个对于内存不大的服务器,比如云主机就太致命了,利用命令:ps aux|grep php-cgi|grep -v grep|awk '{if($4>=1)print $2}' 可以查询占比1%的php-cgi的pid,然后kill掉(kill -9),这个方法比较好)
    官方的解决办法是降低PHP_FCGI_MAX_REQUESTS的值。

    Nginx&PHP-FPM

    这里先简单说一下nginx+php-fpm模式的工作原理:

    1. nginx服务器fork出n个子进程(worker),php-fpm管理器fork出n个子进程。
    2. 当有用户请求,nginx的一个worker接收请求,并将请求抛到socket中。
    3. php-fpm空闲的子进程监听到socket中有请求,接收并处理请求。

    这里要重点说一下第三步骤。第三步涉及到php-fpm进程生命周期的东西。一个php-fpm的生命周期大致是这样的:模块初始化(MINIT)-> 模块激活(RINIT)-> 请求处理 -> 模块停用(RSHUTDOWN) -> 模块激活(RINIT)-> 请求处理 -> 模块停用(RSHUTDOWN)……. 模块激活(RINIT)-> 请求处理 -> 模块停用(RSHUTDOWN)-> 模块关闭(MSHUTDOWN)。在一个php-fpm进程的生命周期里,会有多次的模块激活(RINIT)-> 请求处理 -> 模块停用(RSHUTDOWN)的过程。这个“请求处理”的大致过程是这样的:php读取相应的php文件,对其进行词法分析,生成opcode,zend虚拟机执行opcode。

    PHP配置文件里面的memory_limit 这个东西,其实,它限制的只是这个“请求处理”的内存。所以,这个参数跟php-fpm进程占用的内存并没有什么关系。php是用c写的,所以,难免又会一些内存泄露。也就是说,在“请求处理”这个过程结束后,有些变量没有被销毁,然后就导致一个php-fpm进程占用的内存越来越大。

    那么,有什么办法能阻止这个问题呢?
    php-fpm.conf中有个参数pm.max_requests,等同于PHP_FCGI_MAX_REQUESTS。该值的意思是一个fpm进程处理多少个请求后自动杀掉另起新进程。
    这个参数默认是关闭的,我们需要开启这个参数,并且适当降低这个值,用以让php-fpm自动的释放内存。另一个跟它有关联的值max_children,这个是每次php-fpm会建立多少个进程,这样实际上的内存消耗是max_children*max_requests*每个请求使用内存,根据这个我们可以预估一下内存的使用情况,就不用再写脚本去kill了。

    参考文章
    第七节 内存泄漏
    nginx+php-fpm模式php内存泄漏探究
    PHP+FPM导致内存耗光的问题

    展开全文
  • Tensorflow 内存泄漏问题

    千次阅读 2018-08-13 15:11:59
    session和graph没有释放内存。使用了with关键字可以在session异常退出时也释放内存,否则要用session.close()关闭session。代码如下: session一定要释放: with tf.Seesion() as session: # 在session内部加载...

    session和graph没有释放内存。使用了with关键字可以在session异常退出时也释放内存,否则要用session.close()关闭session。代码如下:

    session一定要释放:

    with tf.Seesion() as session:
        # 在session内部加载保存好的graph
        saver = tf.train.import_meta_graph('./crack_captcha.model-9900.meta')
        saver.restore(session, "./crack_captcha.model-9900.meta")
        # codes

    在session中加载graph(训练好的模型),导致每次关闭程序再运行,graph出现重复加载的现象(尤其是重复加载模型的时候容易导致内存溢出):

    # 用with新建一个graph,这样在运行完以及异常退出时就会释放内存
    graph = tf.Graph()
    with graph.as_default():
        saver = tf.train.import_meta_graph('./crack_captcha.model-9900.meta')
        with tf.Session(graph=graph) as session:
            saver.restore(session, "./CNN_cracks")
    展开全文
  • JVM -Xmx内存设置超过物理内存...5. JVM会因为临近物理内存大小而发生GC吗问题验证测试代码测试Xmx最大值WindowsLinux测试内存溢出开启SWAP情况下关闭SWAP情况下测试GC现象关闭Swap打开Swap其他说明 问题提出 JVM是否可

    问题提出

    JVM是否可以设置-Xmx超过物理内存?如果设置,当内存使用接近物理内存后会发生什么现象?会发生GC吗?

    理论思考

    1. 是否可以设置-Xmx超过物理内存?

    • 可以。
    • JVM并不在启动时申请如此大的内存。适当的超出物理内存是允许的。

    2. 是否可以将-Xmx设置的无限大?

    • 不可以。
    • JVM的一些垃圾回收算法,会使用到卡表(card tables)、 bitmap等,如果JVM检验到Heap区内存大到无法创建这些引用,或着直接超出操作系统可以预定的最大内存,会报错。
    • 这个具体的值跟操作系统、JVM版本、物理机内存等都有关系

    3. 当物理机内存耗尽时,会发生什么现象?

    • 以Linux为例,如果 开启了Swap
      • 内存耗尽时会使用Swap,系统会出现抖动 (thrashing) 现象,系统性能会急剧下降
    • 如果未开启Swap,内存耗尽,或着 Swap 区也耗尽 时会发生什么?
      • 会发生无法分配内存

    4. JVM在堆内存不足和物理内存耗尽时会发生什么?

    1. 持续分配对象,首先在Eden区上无法分配对象时,会先触发 YoungGC
      1. 在触发YoungGC前,如果老年代剩余空间小于年轻代现有所有对象,且小于历次进入老年代的平均大小时,会先触发老年代空间分配担保,进行FullGC
    2. 如果对象长期存活,或着GC后触发动态年龄判断,对象会进入老年代,如果老年代装满时,触发 FullGC
    3. 触发 FullGC 后会有以下几种情况
      1. 如果是刚启动时,由于JVM启动时会先使用一个较小的内存(默认1/64内存大小),当GC后内存不足且没有到达 -Xmx 最大值时,会发生 堆扩容
        1. 如果扩容时无法申请内存,将发生 JVM物理内存无法申请 错误
      2. 如果因启用 Swap 区后,系统性能下降,GC的时间持续太长后,可能会触发 OOM 超出GC开销限制 错误
        1. JVM如果花了98%的时间进行垃圾回收,而只得到2%可用的内存,频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收)时,会报这个错误
      3. 如果在 FullGC 之后,未回收太多的空间,仍然无法放下对象时,会触发 OOM 堆内存溢出 错误

    5. JVM会因为临近物理内存大小而发生GC吗

    1. 不会。
    2. JVM是否发生YoungGCFullGC始终与JVM堆内存的使用情况有关,与物理内存没有直接的关系
    3. 如果不考虑Swap,通常未到达物理内存大小时,JVM就因为无法扩容而崩溃了

    问题验证

    测试代码

    不断往static list中添加一个10M的对象,让内存溢出

    import java.util.LinkedList;
    import java.util.List;
    import java.util.concurrent.TimeUnit;
    public class TestGC {
        private static final List<TestGC> list = new LinkedList<>();
        public byte[] bytes = new byte[10*1024*1024];
        public static void main(String[] args) throws InterruptedException {
            // TimeUnit.SECONDS.sleep(15);
            long count = 0;
            for(;;){
                System.out.println(count++);
                list.add(new TestGC());
                // TimeUnit.MILLISECONDS.sleep(1000);
            }
        }
    }
    

    测试Xmx最大值

    Windows

    • 测试环境

      • 操作系统 Window 10
      • JDK 1.8.0_241
      • 物理内存 16GB
    • java -Xmx100g TestGC

      • 正常启动
    • java -Xmx1400g TestGC

    Error occurred during initialization of VM
    Unable to allocate 2867200KB card tables for parallel garbage collection for the requested 1468006400KB heap.
    Error: Could not create the Java Virtual Machine.
    Error: A fatal exception has occurred. Program will exit.
    
    • java -Xmx1600g TestGC
    Error occurred during initialization of VM
    Unable to allocate 52428800KB bitmaps for parallel garbage collection for the requested 1677721600KB heap.
    Error: Could not create the Java Virtual Machine.
    Error: A fatal exception has occurred. Program will exit.
    

    不在Windows下测试OOM情况,只测试是否可以启动

    Linux

    • 测试环境

      • 操作系统:CentOS 7.9
      • JDK: openjdk 1.8.9_292
      • 物理内存:2GB
      • SWAP: 2GB
    • java -Xmx40t TestGC

      • 正常启动
    • java -Xmx87t TestGC

      • 报错
    Error occurred during initialization of VM
    Could not reserve enough space for 93415538688KB object heap
    
    

    测试内存溢出

    开启SWAP情况下

    • -Xmx 大于物理内存,但小于(物理内存+Swap)
      • java -Xmx3g TestGC
      • 在打印到 142 (内存接近1.5GB)时,速度开始明显下降
      • 最后打印到 295 (内存接近3GB)时,报错 OOM 堆内存溢出
    ...
    293
    294
    295
    Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at TestGC.<init>(TestGC.java:7)
        at TestGC.main(TestGC.java:14)
    
    • -Xmx 大于物理内存,且大于(物理内存+SWAP)
      • java -Xmx8g TestGC
      • 在打印到 142 时,速度开始明显下降
      • 最后打印到 199 时,报错 JVM 无法分配内存
    ...
    196
    197
    198
    199
    OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006e2e95000, 1338490880, 0) failed; error='无法分配内存' (errno=12)
    #
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (mmap) failed to map 1338490880 bytes for committing reserved memory.
    # An error report file with more information is saved as:
    # /root/test-java/hs_err_pid3770.log
    

    关闭SWAP情况下

    • 无论 java -Xmx3g TestGC 还是 java -Xmx8g TestGC 结果均如下
      • 最后打印到 89 时,报错 JVM 无法分配内存
    ...
    83
    84
    85
    86
    87
    88
    89
    OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006f5c83000, 601100288, 0) failed; error='无法分配内存' (errno=12)
    #
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (mmap) failed to map 601100288 bytes for committing reserved memory.
    # An error report file with more information is saved as:
    # /root/test-java/hs_err_pid3917.log
    

    测试GC现象

    • 将代码中的注释放开

    关闭Swap

    • 使用 jstat -gc PID 1000 10000 跟踪如下
     S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
    1024.0 1024.0  0.0    0.0    8192.0   507.9    20480.0      0.0     4480.0 875.7  384.0   76.6       0    0.000   0      0.000    0.000
    1024.0 1024.0  0.0    0.0    8192.0   507.9    20480.0    10240.0   4480.0 875.7  384.0   76.6       0    0.000   0      0.000    0.000
    1024.0 1024.0  0.0    0.0    8256.0    0.0     30724.0    20743.0   4864.0 3003.3 512.0  287.0       1    0.001   1      0.001    0.002
    1728.0 1728.0  0.0    0.0   13888.0  10240.0   34572.0    20743.0   4864.0 3003.6 512.0  287.0       2    0.001   2      0.003    0.004
    1728.0 1728.0  0.0    0.0   13888.0  10240.0   34572.0    30983.0   4864.0 3004.0 512.0  287.0       3    0.003   2      0.003    0.006
    3392.0 3392.0  0.0    0.0   27584.0  10240.0   68708.0    41223.1   4864.0 3004.0 512.0  287.0       4    0.005   3      0.004    0.009
    3392.0 3392.0  0.0    0.0   27584.0  21022.0   68708.0    41223.1   4864.0 3004.0 512.0  287.0       4    0.005   3      0.004    0.009
    ...
    33280.0 33280.0  0.0   30721.4 266496.0 230392.1  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
    33280.0 33280.0  0.0   30721.4 266496.0 240632.1  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
    33280.0 33280.0  0.0   30721.4 266496.0 250872.2  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
    33280.0 33280.0  0.0   30721.4 266496.0 261112.2  666044.0   624904.5  4864.0 3007.0 512.0  287.0      11    0.233   6      0.025    0.258
    

    并没有看到 在接近物理内存时的 GC,发生时机与预期一致

    打开Swap

    • 现象与关闭时的类似
    • 在临近报错时,可以看到最后两次明显的GC时间变长,说明GC效率下降,系统变慢
     S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT  
    73408.0 73408.0 71680.7 71683.3 587328.0 584592.5 1478424.0  1474827.5  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
    73408.0 73408.0 71681.4 71683.3 587328.0 584592.5 1652572.0  1638667.7  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
    73408.0 73408.0 71682.0 71683.3 587328.0 584592.5 1836964.0  1833228.0  4864.0 3027.2 512.0  287.0      14    1.836   7      0.029    1.865
    73408.0 73408.0 71682.3  0.0   587328.0   0.0    1970136.0  1966351.2  4864.0 3027.2 512.0  287.0      14   22.270   8      0.029   22.299
    73408.0 73408.0  0.0     0.0   587328.0 71682.3  1970136.0  1966351.3  4864.0 3027.2 512.0  287.0      14   22.270   8      0.589   22.859
    

    其他说明

    • 以下现象未复现
      • 由于该现象的条件比较苛刻,不容易复现
      • 复现要求:JVM如果花了98%的时间进行垃圾回收,而只得到2%可用的内存,频繁的进行内存回收(最起码已经进行了5次连续的垃圾回收) 超出GC开销限制
    java.lang.OutOfMemoryError: GC overhead limit exceeded
    
    展开全文
  • 如何检查内存泄露问题

    千次阅读 2019-03-18 11:54:48
    内存泄漏是编程中常常见到的一个问题内存泄漏往往会一种奇怪的方式来表现出来,基本上每个程序都表现出不同的方式。但是一般最后的结果只有两个,一个是程序当掉,一个是系统内存不足。还有一种就是比较介于中间的...

    简单说一下在没有工具的情况如何运用VC库中的工具来检查代码的内存泄漏问题。

    一: 内存泄漏 

            内存泄漏是编程中常常见到的一个问题,内存泄漏往往会一种奇怪的方式来表现出来,基本上每个程序都表现出不同的方式。 但是一般最后的结果只有两个,一个是程序当掉,一个是系统内存不足。 还有一种就是比较介于中间的结果程序不会当,但是系统的反映时间明显降低,需要定时的Reboot才会正常。 

    有一个很简单的办法来检查一个程序是否有内存泄漏。就是是用Windows的任务管理器(Task Manager)。运行程序,然后在任务管理器里面查看 “内存使用”和”虚拟内存大小”两项,当程序请求了它所需要的内存之后,如果虚拟内存还是持续的增长的话,就说明了这个程序有内存泄漏问题。 当然如果内存泄漏的数目非常的小,用这种方法可能要过很长时间才能看的出来。 

    当然最简单的办法大概就是用CompuWare的BoundChecker 之类的工具来检测了,不过这些工具的价格对于个人来讲稍微有点奢侈了。 

    如果是已经发布的程序,检查是否有内存泄漏是又费时又费力。所以内存泄漏应该在Code的生成过程就要时刻进行检查。 

     

    二: 原因

    内存泄漏产生的原因一般是三种情况: 

    1. 分配完内存之后忘了回收; 

    2. 程序Code有问题,造成没有办法回收; 

    3. 某些API函数操作不正确,造成内存泄漏。 

    1. 内存忘记回收,这个是不应该的事情。但是也是在代码种很常见的问题。分配内存之后,用完之后,就一定要回收。如果不回收,那就造成了内存的泄漏,造成内存泄漏的Code如果被经常调用的话,那内存泄漏的数目就会越来越多的。从而影响整个系统的运行。比如下面的代码: 

    for (int =0;I<100;I++)

    {

    Temp = new BYTE[100];

    }

    就会产生 100*100Byte的内存泄漏。 

    2. 在某些时候,因为代码上写的有问题,会导致某些内存想回收都收不回来,比如下面的代码: 

    Temp1 = new BYTE[100];

    Temp2 = new BYTE[100];

    Temp2 = Temp1;

    这样,Temp2的内存地址就丢掉了,而且永远都找不回了,这个时候Temp2的内存空间想回收都没有办法。 

    3. API函 数应用不当,在Windows提供API函数里面有一些特殊的API,比如FormatMessage。 如果你给它参数中有FORMAT_MESSAGE_ALLOCATE_BUFFER,它会在函数内部New一块内存Buffer出来。但是这个 buffer需要你调用LocalFree来释放。 如果你忘了,那就会产生内存泄漏。 

     

    三: 检查方法

            一 般的内存泄漏检查的确是很困难,但是也不是完全没有办法。如果你用VC的库来写东西的话,那么很幸运的是,你已经有了很多检查内存泄漏的工具,只是你想不想用的问题了。Visual C++的Debug版本的C运行库(C Runtime Library)。它已经提供好些函数来帮助你诊断你的代码和跟踪内存泄漏。 而且最方便的地方是这些函数在Release版本中完全不起任何作用,这样就不会影响你的Release版本程序的运行效率。 

    比如下面的例子里面,有一个明显的内存泄漏。当然如果只有这么几行代码的话,是很容易看出有内存泄漏的。但是想在成千上万行代码里面检查内存泄漏问题就不是那么容易了。 

    char * pstr = new char[5];

    lstrcpy(pstr,"Memory leak");

    如果我们在Debug版本的Code里面对堆(Heap)进行了操作,包括malloc, free, calloc, realloc, new 和 delete可以利用VC Debug运行时库中堆Debug函数来做堆的完整性和安全性检查。比如上面的代码,lstrcpy的操作明显破坏了pstr的堆结构。使其溢出,并破坏 了临近的数据。那我们可以在调用lstrcpy之后的代码里面加入 _CrtCheckMemory函数。_CrtCheckMemory函数发现前面的lstrcpy使得pstr的堆结构被破坏,会输出这样的报告: 

    memory check error at 0x00372FA5 = 0x79, should be 0xFD.

    memory check error at 0x00372FA6 = 0x20, should be 0xFD.

    memory check error at 0x00372FA7 = 0x6C, should be 0xFD.

    memory check error at 0x00372FA8 = 0x65, should be 0xFD.

    DAMAGE: after Normal block (#41) at 0x00372FA0.

    Normal located at 0x00372FA0 is 5 bytes long.

    它告诉说 pstr的长度应该是5个Bytes,但是在5Bytes后面的几个Bytes也被非法改写了。提醒你产生了越界操作。_CrtCheckMemory 的返回值只有TRUE和FALSE,那么你可以用_ASSERTE()来报告出错信息。 上面的语句可以换成 _ASSERTE(_CrtCheckMemory()); 这样Debug版本的程序在运行的时候就会弹出一个警告对话框,这样就不用在运行时候一直盯着Output窗口看了。这个时候按Retry,就可以进入源 代码调试了。看看问题到底出在哪里。

    其他类似的函数还有:

    _CrtDbgReport, _CrtDoForAllClientObjects, _CrtDumpMemoryLeaks,_CrtIsValidHeapPointer, _CrtIsMemoryBlock, 

    _CrtIsValidPointer,_CrtMemCheckpoint, _CrtMemDifference, _CrtMemDumpAllObjectsSince, _CrtMemDumpStatistics, 

    _CrtSetAllocHook, _CrtSetBreakAlloc, _CrtSetDbgFlag,_CrtSetDumpClient, _CrtSetReportFile, _CrtSetReportHook, 

    _CrtSetReportMode 

    这些函数全部都可以用来在Debug版本中检查内存的使用情况。具体怎么使用这些函数就不在这里说明了,各位可以去查查MSDN。在这些函数中用处比较大的,或者说使用率会比较高的函数是_CrtMemCheckpoint, 设置一个内存检查点。这个函数会取得当前内存的运行状态。 _CrtMemDifference 检查两种内存状态的异同。 _CrtMemDumpAllObjectsSince 从程序运行开始,或者从某个内存检查点开始Dump出堆中对象的信息。还有就是_CrtDumpMemoryLeaks当发生内存溢出的时候Dump出堆 中的内存信息。 _CrtDumpMemoryLeaks一般都在有怀疑是内存泄漏的代码后面调用。比如下面的例子: 

    #include <windows.h>

    #include <crtdbg.h>

    void main()

    {

    char * pstr;

    pstr = new char[5];

    _CrtDumpMemoryLeaks();

    }

    输出:

    Detected memory leaks! à提醒你,代码有内存泄漏.

    Dumping objects ->

    {44} normal block at 0x00372DB8, 5 bytes long.

    Data: < > CD CD CD CD CD 

    Object dump complete.

    如果你双击包含行文件名的输出行,指针将会跳到源文件中内存被分配地方的行。当无法确定那些代码产生了内存泄漏的时候,我们就需要进行内存状态比较。在可疑的代码段的前后设置内存检查点,比较内存使用是否有可疑的变化。以确定内存是否有泄漏。为此要先定义三个_CrtMemState 对象来保存要比较的内存状态。两个是用来比较,一个用了保存前面两个之间的区别。 

    _CrtMemState Sh1,Sh2,Sh_Diff;

    char *pstr1 = new char[100];

    _CrtMemCheckPoint(&Sh1); ->设置第一个内存检查点

    char *pstr2 = new char[100];

    _CrtMemCheckPoint(&Sh2); ->设置第二个内存检查点

    _CrtMemDifference(&Sh_Diff, &Sh1, &Sh2); ->检查变化

    _CrtMemDumpAllObjectsSince(&Sh_Diff); ->Dump变化

    如果你的程序中使用了MFC类库,那么内存泄漏的检查方法就相当的简单了。因为Debug版本的MFC本身就提供一部分的内存泄漏检查。 大部分的new 和delete没有配对使用而产生的内存泄漏,MFC都会产生报告。这个主要是因为MFC重载了Debug版本的new 和delete操作符, 并且对前面提到的API函数重新进行了包装。在MFC类库中检查内存泄漏的Class就叫 CMemoryState,它重新包装了了_CrtMemState,_CrtMemCheckPoint, _CrtMemDifference, _CrtMemDumpAllObjectsSince这些函数。并对于其他的函数提供了Afx开头的函数,供MFC程序使用。比如 AfxCheckMemory, AfxDumpMemoryLeaks 这些函数的基本用法同上面提到的差不多。 CMemoryState和相关的函数的定义都在Afx.h这个头文件中。 有个简单的办法可以跟踪到这些函数的声明。在VC中找到MFC程序代码中下面的代码, 一般都在X.cpp的开头部分 

    #ifdef _DEBUG

    #define new DEBUG_NEW

    #undef THIS_FILE

    static char THIS_FILE[] = __FILE__;

    #endif 

    把光标移到DEBUG_NEW上面 按F12,就可以进入Afx.h中定义这些Class和函数的代码部分。 VC中内存泄漏的常规检查办法主要是上面的两种。当然这两种方法只是针对于Debug版本的Heap的检查。如果Release版本中还有内存泄漏,那么检查起来就麻烦很多了。 

    4 .总结:

            实际上Heap的内存泄漏问题是相当的好查的。VC的提供的检查工具也不太少,但是如果是栈出了什么问题,恐怕就麻烦很多了。栈出问题,一般不会产生内存泄漏,但是你的代码的逻辑上很有可能会有影响。这个是最最痛苦的事情。 编程,就是小心,小心再小心而已。

    展开全文
  • Hadoop之内存问题

    千次阅读 2017-11-19 09:57:54
    一 发生很多Job OOM现象 那几天运维发现很多OOM,一直不断在Full GC。我们知道Full GC一旦发生超过几分钟,其他的线程均停止工作,只有垃圾回收线程工作。 第一个猜想是运行的Job,也就是我们运行任务内存资源不够用...
  • 内存问题定位总结

    千次阅读 2018-05-31 10:43:51
    现象:挂死,程序跑的异常,数据被串改大致原因:数组越界,字符串操作越界,栈指针操作越界,操作了释放掉了的指针,多线程时序对资源保护控制不当,内存管理异常,使用了其他地方的内存定位方法:1. 类似内存泄漏...
  • Tensorflow 内存泄露问题

    万次阅读 2017-09-15 22:52:05
    使用tensorflow进行编程时,经常遇到操作不当,带来的内存泄露问题,这里一个可以帮助debug问题所在方法: ...
  • malloc申请内存问题

    千次阅读 2019-09-17 20:26:39
    具体问题是这样的,首先malloc申请一块内存,但使用时比实际的大一个字节,比如我申请了52个字节,使用了53个或者申请50个使用了51个,然后我发现的现象是当我申请了52个字节使用了53个字节的时候,程序肯定会挂掉,...
  • 内存泄露问题分析方法

    千次阅读 2015-11-07 12:24:47
    本文介绍了内存泄露的定位方法,可以帮助Android系统的开发者定位一些常见的内存泄露问题。本文暂时只从工具的角度讲解了如何定位,后面会补充如何从代码的角度去分析和定位,并且加入内存管理的优化方法。
  • 启动内存溢出问题

    千次阅读 2018-07-12 11:09:52
    现象:npm或者webpack启动项目报内存溢出 处理:要找到对应的npm或者webpack的cmd执行命令文件,然后加上参数max_old_space_size=4096 例如 node --max_old_space_size=4096 "%~dp0\node_modules\webpack-...
  • 关于内存越界的问题

    千次阅读 2014-04-03 17:05:35
    在上家公司的时候,服务器了一个很郁闷的问题,做压力测试的时候,一旦人数上到1000多的时候,会不定时的出现崩溃现象,虽然崩溃的地方相同,但是和崩溃的起始点已经相差很远,gdb的断点基本上用处不大。...
  • Malloc内存泄露和内存越界问题的研究 2013-03-02 22:59:32 分类: LINUX 原文地址:Malloc内存泄露和内存越界问题的研究 作者:gongcb Malloc内存泄露和内存越界问题的研究 ------内存跟踪与检测篇 ...
  • 但明明在配置硬件时使用的DDR SDRAM,程序应该在SDRAM上执行才对,而DDR一般容量很大,不可能出现这个问题,仔细分析发现SDK在链接代码时使用了一个lscript.ld 程序执行的时候是需要堆和栈,动态分配...
  • 上次个项目中要用到rapidjson生成json格式的数据文档,由于第一次用rapidjson,中间出现了疑似内存泄漏的问题,具体现象就是程序占用的内存不断在增加,debug过程中发现只要用rapidjson生成json数据后,内存占用就...
  • IE内存泄漏问题总结

    千次阅读 2013-04-10 18:29:28
    IE内存泄漏模型 l 页面内脚本的动态刷新操作导致IE内存持续上升 l 页面内用F5或右键反复刷新,导致内存不断飙升 l 页面内变量占用的内存在退出该页面后,内存仍然无法回收 l 页面内变量占用的内存在退出该页面...
  • Java垃圾回收机制(GC) 1.1 GC机制作用 1.2 堆内存3代分布(年轻代、老年代...2.3 ML(内存泄露) OOM(内存溢出)问题现象及分析 2.4 IBM DUMP分析工具使用介绍 Java应用CPU、线程问题分析 Java垃圾回收机制(GC)
  • 普通内存、ECC内存和REG ECC内存有什么不同? 前言 我们都知道,在INTEL平台,北桥负责与CPU的联系,并控制内存、AGP、PCI数据在北桥内部传输。基本上只要主板芯片组确定,那么其支持的内存类型也就确定了。 ...
  • 系统内存溢出问题排查

    千次阅读 2018-02-27 16:51:26
    2018年1月23号凌晨6:00左右,公司向银行推送交易的系统(以下简称推送系统)报异常java.lang.OutOfMemoryError: Java heap space,随后系统挂掉了,系统的定时任务无法再启动,但因为没有添加监控,未能及时发现...
  • c++内存泄漏和内存碎片的问题

    千次阅读 2017-12-23 20:01:08
    1.内存泄漏的定义    一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的,大小任意的(内存块的大小可以在程序运行期决定),使用完后必须显示释放的内存。应用程序一般使用malloc,realloc...
  • java 内存溢出问题解析

    千次阅读 2017-03-16 20:10:42
    java.lang.OutOfMemoryError: Metaspace 两种错误皆为内存泄露异常,但是引起原因却不同,第一种为线程引起,第二种为Metaspace 空间不足 ...问题1:Druid-ConnectionPool-Create-1180222211 线程抛了Out
  • 在进入压力测试阶段期间,发现了gateway有内存泄漏问题问题发现的起因是,当时启动一台gateway,一台对应的下游应用服务,在压力测试期间,发现特别不稳定,并发量时高时低,而且会施压机卡住的现象,...
  • 记一次fastjson引起的内存泄漏问题

    千次阅读 2019-09-14 12:34:47
    记一次fastjson引起的内存泄漏在了解是什么引发了问题之前,先解决一些工具和概念上的问题一、Jmeter(对jmeter已经了解的同学可以略过这个部分)二、服务器指标和参数三、观察到的现象和为了提升tps针对性的改进...
  • Java堆外内存增长问题排查Case

    千次阅读 2018-11-27 20:00:53
    最近排查一个线上java服务常驻内存异常高的问题,大概现象是:java堆Xmx配置了8G,但运行一段时间后常驻内存RES从5G逐渐增长到13G #补图#,导致机器开始swap从而服务整体变慢。 由于Xmx只配置了8G但RES常驻内存达到...
  • Java内存泄露问题

    千次阅读 热门讨论 2005-01-12 19:26:00
    内存泄露很多人在谈论内存泄露问题,当然对于c/c++来说,这个应该是老掉牙的问题,但是很多Java人员也越来越多得讨论这个问题,我这里写个小结,希望对大家一定的参考价值。 必须先要了解的1.c/c++是程序员自己...
  • 关于JavaFX中内存泄露问题

    千次阅读 2013-07-30 19:48:24
    最近参与了一个JavaFX的项目,负责其中的性能测试等工作,作为一个“用户”在测试的过程中,发现其中很严重的稳定性问题。主要表现为:操作一段时间后,VisualVM监测占用内存持续攀升,最终界面卡死,出现内存溢出...
  • 这篇文章的全称应该叫:[在某些内核版本上,cgroup 的 kmem account 特性有内存泄露问题],如果你遇到过 pod 的 cannot allocated memory 报错,node 内核日志的 SLUB: Unable to allocate memory on node -1 报错,...
  • 问题定位:内存泄漏,踩内存

    万次阅读 2013-07-27 00:27:40
    1.内存泄漏  确定现象: ... vxworks系统,内存是否相关信息???  如果快速泄漏内存,则较容易判断。如果是非常慢的,则要经过一定时间场景复现后,应该也能看出来。  linux在内存耗光后,会

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 526,322
精华内容 210,528
关键字:

内存出问题有什么现象