php守護進程可能的內存泄漏,php內存泄漏排查

本文目錄一覽：

1、如何將我的php腳本以守護進程的方式一直運行
2、PHP CURL內存泄露的解決方法
3、php內存溢出問題，求教大神！
4、php 執行mysql中查詢時內存溢出怎麼辦
5、哪些情況會內存泄漏

如何將我的php腳本以守護進程的方式一直運行

寫好php腳本。建議定期檢測內存佔用，核心邏輯就不寫了。這個跟業務有關。

if(memory_get_usage()100*1024*1024){

exit(0);//大於100M內存退出程序，防止內存泄漏被系統殺死導致任務終端

}

假設該php文件的路徑為/root/run.php

打開終端

setsid php /root/run.php /dev/null

編輯進程監控腳本，當進程不存在時，自動重啟 /root/monitor.sh

#!/bin/bash

alive=`ps aux|grep root\/run|grep -v grep|wc -l`

if [ $alive -eq 0]

then

php /root/run.php /dev/null

添加計劃任務（每分鐘檢測一次）

crontab -e

* * * * * /root/monitor.sh /dev/null

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 (destination in request headers).

4）1.1.1.1 write back to you the response receive from

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 ).

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). ;

php內存溢出問題，求教大神！

你看看你的程序裡面有沒有用到遞歸，或者有沒有死循環。

另外解決此類問題的主要思想就是分而治之

我覺得是foreach的機制的問題

foreach($arr as $key=$value){}這裡面的$value是每次循環是把數組中元素的值賦值給$value

而foreach($arr as $key=$value){}這裡的$value是引用賦值。

兩者有什麼區別呢？帶引用的$value可以$value=’aaa’;直接改變元素的值；還有一個重要的，就是最後一次循環之後$value的值還會保留；

你這裡是foreach($obj as $value){}對象默認是引用傳值；所以循環過後要unset($obj);

php里還有一個函數clearstatcache(true)清楚文件狀態緩存，雖然受影響的函數沒有simplexml_load_file(),不過還是可以試試；

還有mysql系列的函數很多也不是很穩定，有時候不知道會出什麼問題；建議用PDO;

深感php裡面的坑太多了，稍不注意就跳進去了。

php 執行mysql中查詢時內存溢出怎麼辦

使用mysql_unbuffered_query(), 可以避免內存的立即佔用, 如果返回的結果存放到array中也是完全沒有問題的, 也不會出現php查詢mysql數據量過大時導致內存溢出問題.

這種情況一般會在單表數據表資料庫比較大的時候出現，建議在使用的過程中限制單次讀取數據條數，或者對數據表進行分表

哪些情況會內存泄漏

1、資源釋放問題

。 Android 程序代碼的問題，長期保持某些資源，如 Context、Cursor、IO 流的引用，資源得不到釋放造成內存泄露。

2、對象內存過大問題

保存了多個耗用內存過大的對象（如 Bitmap、XML 文件），造成內存超出限制。

3、static 關鍵字的使用問題

static 是 Java 中的一個關鍵字，當用它來修飾成員變數時，那麼該變數就屬於該類，而不是該類的實例。所以用 static 修飾的變數，它的生命周期是很長的，如果用它來引用一些資源耗費過多的實例（Context 的情況最多），這時就要謹慎對待了。

public class ClassName { private static Context mContext; //省略 }

以上的代碼是很危險的，如果將 Activity 賦值到 mContext 的話。那麼即使該 Activity 已經 onDestroy，但是由於仍有對象保存它的引用，因此該 Activity 依然不會被釋放。

我們舉 Android 文檔中的一個例子。

private static Drawable sBackground;

@Override protected void onCreate(Bundle state) {

super.onCreate(state);

TextView label = new TextView(this); //getApplicationContext label.setText(“Leaks are bad”);

if (sBackground == null) {

sBackground = getDrawable(R.drawable.large_bitmap);

}

label.setBackgroundDrawable(sBackground); setContentView(label);

}

sBackground 是一個靜態的變數，但是我們發現，我們並沒有顯式的保存 Context 的引用，但是，當 Drawable 與 View 連接之後，Drawable 就將 View 設置為一個回調，由於 View 中是包含 Context 的引用的，所以，實際上我們依然保存了 Context 的引用。這個引用鏈如下： Drawable-TextView-Context 所以，最終該 Context 也沒有得到釋放，發生了內存泄露。

針對 static 的解決方案

① 應該盡量避免 static 成員變數引用資源耗費過多的實例，比如 Context。

② Context 盡量使用 ApplicationContext，因為 Application 的 Context 的生命周期比較長，引用它不會出現內存泄露的問題。 ③ 使用 WeakReference 代替強引用。比如可以使用 WeakReference mContextRef;

4、線程導致內存溢出

線程產生內存泄露的主要原因在於線程生命周期的不可控。我們來考慮下面一段代碼。

。

public class MyActivity extends Activity {

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

new MyThread().start();

}

private class MyThread extends Thread{

@Override

public void run() {

super.run(); //do somthing while(true)

}

這段代碼很平常也很簡單，是我們經常使用的形式。我們思考一個問題：假設 MyThread 的 run 函數是一個很費時的操作，當我們開啟該線程後，將設備的橫屏變為了豎屏，一般情況下當屏幕轉換時會重新創建 Activity，按照我們的想法，老的 Activity 應該會被銷毀才對，然而事實上並非如此。由於我們的線程是 Activity 的內部類，所以 MyThread 中保存了 Activity 的一個引用，當 MyThread 的 run 函數沒有結束時，MyThread 是不會被銷毀的，因此它所引用的老的 Activity 也不會被銷毀，因此就出現了內存泄露的問題。有些人喜歡用 Android 提供的 AsyncTask，但事實上 AsyncTask 的問題更加嚴重，Thread 只有在 run 函數不結束時才出現這種內存泄露問題，然而 AsyncTask 內部的實現機制是運用了 ThreadPoolExcutor,該類產生的 Thread 對象的生命周期是不確定的，是應用程序無法控制的，因此如果 AsyncTask 作為 Activity 的內部類，就更容易出現內存泄露的問題。

針對這種線程導致的內存泄露問題的解決方案：

第一、將線程的內部類，改為靜態內部類（因為非靜態內部類擁有外部類對象的強引用，而靜態類則不擁有）。

第二、在線程內部採用弱引用保存 Context 引用。

原創文章，作者：ETVW，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/145597.html