PHP CURL内存泄露的解决方法

PHP CURL内存泄露的解决方法

curl配置平淡无奇拍燃，长时间运行发现一个严困贺中重问题，内存泄露！不论用单线程和多线程都无法避免！是curl访问https站点的时候有bug！

内存汪山泄露可以通过linux的top命令发现，使用php函数memory_get_usage()不会发现。

经过反复调试找到解决办法，curl配置添加如下几项解决问题：

复制代码 代码如下:

[CURLOPT_HTTPPROXYTUNNEL] = true

[CURLOPT_SSL_VERIFYPEER] = false

[CURLOPT_SSL_VERIFYHOST] = false

CURLOPT_HTTPPROXYTUNNEL具体说明stackoverflow上有，直接贴原文：

Without CURLOPT_HTTPPROXYTUNNEL

Without CURLOPT_HTTPPROXYTUNNEL : You just use the proxy address/port as a destination of your HTTP request. The proxy will read the HTTP headers of your query, forward your request to the destination (with your HTTP headers) and then write the response to you.

Example steps :

1）HTTP GET / sent to 1.1.1.1 (proxy)

2）1.1.1.1 receive request and parse header for getting the final destination of your HTTP request.

3）1.1.1.1 forward your query and headers to www.site.com (destination in request headers).

4）1.1.1.1 write back to you the response receive from www.site.com

With CURLOPT_HTTPPROXYTUNNEL

With CURLOPT_HTTPPROXYTUNNEL : You ask the proxy to open a direct binary connection (like HTTPS, called a TCP Tunnel) directly to your destination by doing a CONNECT HTTP request. When the tunnel is ok, the proxy write you back a HTTP/1.1 200 Connection established. When it received your browser start to query the destination directly : The proxy does not parse HTTP headers and theoretically does not read tunnel datas, it just forward it, thats why it is called a tunnel !

Example steps :

1）HTTP CONNECT sent to 1.1.1.1

2）1.1.1.1 receive HTTP CONNECT and get the ip/port of your final destination (header field of HTTP CONNECT).

3）1.1.1.1 open a TCP Socket by doing a TCP handshake to your destination 2.22.63.73:80 (ip/port of www.site.com).

4）1.1.1.1 Make a tunnel by piping your TCP Socket to the TCP Socket opened to 2.22.63.73:80and then write you back HTTP/1.1 200 Connection established witch means that your client can now make your query throw the TCP Tunnel (TCP datas received will be transmited directly to server and vice versa).

最原始的内存泄露测试

重复多次 *** 作关键的可疑的路径，从内存监控工具中观察内存曲线，是否存在不断上升的趋势且不会在程序返回时明显回落。

这种方式可以发现最基本，也是最明显的内存泄露问题，对用户价值最大， *** 作难度小，性价比极高。

MAT内存分析工具

2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露

在Devices 中，点击要监控的程序。

点击Devices视图界面中最上方一排图标中的“Update Heap”

点击Heap视图

点击Heap视图中的“Cause GC”按钮

到此为止需检测的进程就可以被监视。Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：

进入某应用，不断的 *** 作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造虚岁判成对象不被垃圾回收的情况。

所以说虽然我们不断的 *** 作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着 *** 作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。

2.2 MAT分析hprof来定位内存泄露的原因所在。

这是出现内存泄露后使用MAT进行问题定位的有效手段。

A)Dump出内存泄露当时的内存镜像hprof，分析怀疑泄露的类：

B)分析持有此类对象引用的外部对象

C)分析这些持有引用的对象的GC路径

D)逐个分析每个差改对象的GC路径是否正常

从这个路径可以看出是一个antiRadiationUtil工具类对象持有了MainActivity的引用导致MainActivity无法释放。此时就要进入代码分析此时antiRadiationUtil的引用持有是否合理（如果antiRadiationUtil持有了MainActivity的context导致节目退出后MainActivity无法销毁，那一般都属于内存泄露了）。

2.3 MAT对比 *** 作前后的hprof来定位内存泄露的根因所在。

为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去

A） 第一个HPROF 文件(usingFile >Open Heap Dump ).

B）打开Histogram view.

C）在NavigationHistory view里 (如果看不到就从Window >show view>MAT- Navigation History ), 右击histogram然后选择Add to Compare Basket .

D）打开第二个HPROF 文件然后重做步骤2和3.

E）切换到Compare Basket view, 然后点击Compare the Results (视图右上角的红色”!”图标)。

F）分析对比结果

可以看出两个hprof的数据对象对比结果。

通过这种方式可以快速定位到 *** 作前后所持有的对象增量，从而进一步定位出当前 *** 作导致内存泄露的具体原因是泄露了什么数据对象。

注意：

如果是用 MAT Eclipse 插件获取的 Dump文件，不需要经过转换则可在MAT中打开，Adt会自动进行转换。

而手机SDk Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)

首先，要通过控制台进入到你的 android sdk tools 目雀亏录下执行以下命令：

./hprof-conv xxx-a.hprof xxx-b.hprof

例如 hprof-conv input.hprof out.hprof

此时才能将out.hprof放在eclipse的MAT中打开。

手机管家内存泄露每日监控方案

目前手机管家的内存泄露每日监控会自动运行并输出是否存在疑似泄露的报告邮件，不论泄露对象的大小。这其中涉及的核心技术主要是AspectJ，MLD自研工具（原理是虚引用）和UIAutomator。

3.1 AspectJ插桩监控代码

手机管家目前使用一个ant脚本加入MLD的监控代码，并通过AspectJ的语法实现插桩。

使用AspectJ的原因是可以灵活分离出项目源码与监控代码，通过不同的编译脚本打包出不同用途的安装测试包：如果测试包是经过Aspect插桩了MLD监控代码的话，那么运行完毕后会输出指定格式的日志文件，作为后续分析工作的数据基础。

3.2 MLD实现监控核心逻辑

这是手机管家内的一个工具工程，正式打包不会打入，BVT等每日监控测试包可以打入。打入后可以通过诸如addObject接口（通过反射去检查是否含有该工具并调用）来加入需要监控的检测对象，这个工具会自动在指定时机（如退出管家）去检测该对象是否发生泄漏。

这个内存泄露检测的基本原理是：

虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用必须和引用队列（ReferenceQueue）联合使用（在虚引用函数就必须关联指定）。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，自动把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。

基于以上原理，MLD工具在调用接口addObject加入监控类型时，会为该类型对象增加一个虚引用，注意虚引用并不会影响该对象被正常回收。因此可以在ReferenceQueue引用队列中统计未被回收的监控对象是否超过指定阀值。

利用PhantomReferences(虚引用)和ReferenceQueue(引用队列)，当PhantomReferences被加入到相关联的ReferenceQueue时，则视该对象已经或处于垃圾回收器回收阶段了。

MLD监控原理核心

目前手机管家已对大部分类完成内存泄露的监控，包括各种activity，service和view页面等，务求在技术上能带给用户最顺滑的产品体验。

接下来简单介绍下这个工具的判断核心。根据虚引用监控到的内存状态，需要通过多种策略来判断是否存在内存泄露。

（1）最简单的方式就是直接在加入监控时就为该类型设定最大存在个数，举个例子，各个DAO对象理论上只能存在最多一个，因此一旦出现两个相同的DAO，那一般都是泄露了；

（2）第二种情况是在页面退出程序退出时，检索gc后无法释放的对象列表，这些对象类型也会成为内存泄露的怀疑对象；

（3）最后一种情况比较复杂，基本原理是根据历史 *** 作判断对象数量的增长幅度。根据对象的增长通过最小二乘法拟合出该对象类型的增长速度，如果超过经验值则会列入疑似泄露的对象列表。

3.3 UIAutomator完成重复 *** 作的自动化

最后一步就很简单了。这么多反复的UI *** 作，让人工来点就太浪费人力了。我们使用UIAutomator来进行自动化 *** 作测试。

目前手机管家的每日自动化测试已覆盖各个功能的主路径，并通过配置文件的方式来灵活驱动用例的增删改查，最大限度保证了随着版本推移用例的复用价值。

至此手机管家的内存泄露测试方案介绍完毕，也欢迎各路牛人交流沟通更多更强的内存泄露工具盒方案！

腾讯Bugly简介

Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到App的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。

(一) 生成.hprof文件

生成.hprof 文件的方法有很多，而且Android 的不同版本中生成.hprof 的方式也稍有差别，我使用的版本的是2.1，各个版本中生成.prof 文件的方法请参考： http://android.git.kernel.org/?p=platform/dalvik.gita=blob_plainf=docs/heapprofiling.htmlhb=HEAD。

1. 打开eclipse 并切换到DDMS 透视图，同时确认Devices、Heap 和logcat 视图已经打开了；

2. 将手机设备链接到电脑，并确保使用“USB 调试”模式链接，而不是“Mass Storage“模式；

3. 链接成功后在Devices 视图中就会看到设备的序列号，和设备中正在运行的部分进程；

4. 点击选中想要分析的应用的进程，在Devices 视图上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”两个按钮；

5. 这是DDMS 工具将会自动生成当前选中进程的.hprof 文件，并将其进行转换后存放在sdcard 当中，如果你已经安装了MAT 插件，那么此时MAT 将会自动被启用，并开始对.hprof 文件进行分析；

注颤搏意：第4 步和茄销祥第5 步能够正常使用前提是我们需要有sdcard，并且当前进程有向sdcard中写入的权限(WRITE_EXTERNAL_STORAGE)，斗缓否则.hprof 文件不会被生成，

在logcat 中会显示诸如 ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.的信息。

如果我们没有sdcard，或者当前进程没有向sdcard 写入的权限（如system_process）， 那我们可以这样做：

6. 在当前程序中，例如framework 中某些代码中，可以使用android.os.Debug 中的： public static void dumpHprofData(String fileName) throws IOException 方法，手动的指定.hprof 文件的生成位置。

例如： xxxButton.setOnClickListener(new View.OnClickListener() { public void onClick(View view) { android.os.Debug.dumpHprofData("/data/temp/myapp.hprof")... ... } }

上述代码意图是希望在xxxButton 被点击的时候开始抓取内存使用信息，并保存在我们指定的位置：/data/temp/myapp.hprof，这样就没有权限的限制了，而且也无须用sdcard。

但要保证/data/temp 目录是存在的。这个路径可以自己定义，当然也可以写成sdcard 当中的某个路径。

(二) 使用MAT导入.hprof文件

1. 如果是eclipse 自动生成的.hprof 文件，可以使用MAT 插件直接打开（可能是比较新的ADT才支持）；

2. 如果eclipse 自动生成的.hprof 文件不能被MAT 直接打开， 或者是使用android.os.Debug.dumpHprofData()方法手动生成的.hprof 文件，则需要将.hprof 文件进行转换，转换的方法： 例如我将.hprof 文件拷贝到PC 上的/ANDROID_SDK/tools 目录下，并输入命令hprofconv xxx.hprof yyy.hprof，其中xxx.hprof 为原始文件，yyy.hprof 为转换过后的文件。转换过后的文件自动放在/ANDROID_SDK/tools 目录下。OK，到此为止，.hprof 文件处理完毕，可以用来分析内存泄露情况了。

3. 在Eclipse 中点击Windows->Open Perspective->Other->Memory Analyzer，或者打Memory Analyzer Tool 的RCP。在MAT 中点击File->Open File，浏览并导入刚刚转换而得到的.hprof文件。

(三) 使用MAT的视图工具分析内存

导入.hprof 文件以后，MAT 会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package 类点右键，在d出菜单中选择List objects->With incoming references。这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots ->exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

MAT 的界面如下图所示。

具体的分析方法在此不做说明了，因为在MAT 的官方网站和客户端的帮助文档中有十分详尽的介绍。 了解MAT 中各个视图的作用很重要，例如www.eclipse.org/mat/about/screenshots.php 中介绍的。

总之使用MAT 分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有被释放，找到没有被释放的原因，也就可以很容易定位代码中的哪些片段的逻辑有问题了。

另外在测试过程首先需要分析怎么样 *** 作一个应用会产生内存泄露然后在不断的 *** 作中抓取该进程产生的hhprof文件使用MAT工具分析。目前自己的了解查看内存分析内存泄露还有以下几种方法：

1.使用top命令查看某个进程的内存。例如创建一个脚本文件music.sh 该文件内容为指定程序每隔一秒钟输出某个进程的内存使用情况，在此具体实现如下 ：

#!/bin/bash

while truedo

adb shell procrank | grep "com.android.music"

sleep 1

done

并且配合使用procank工具可以查看music进程每一秒钟内存使用情况。

2.另外使用top命令也可是查看内存具体为：

adb shell top -m 10.(查看使用资源最多的10个进程)

adb shell top|grep com.android.music(查看music进程的内存)

3.free命令

free

1.作用free命令用来显示内存的使用情况，使用权限是所有用户。

2.格式free [－b|－k|－m] [－o] [－s delay] [－t] [－V]

3.主要参数－b －k －m：分别以字节（KB、MB）为单位显示内存使用情况。

－s delay：显示每隔多少秒数来显示一次内存使用情况。

－t：显示内存总和列。

－o：不显示缓冲区调节列。

4.应用实例free命令是用来查看内存使用情况的主要命令。和top命令相比，它的优点是使用简单，并且只占用很少的系统资源。通过－S参数可以使用free命令不间断地监视有多少内存在使用，这样可以把它当作一个方便实时监控器。

＃free －b －s5使用这个命令后终端会连续不断地报告内存使用情况（以字节为单位），每5秒更新一次。

---