本文目录一览：
如何将我的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
fi
添加计划任务（每分钟检测一次）
crontab -e
* * * * * /root/monitor.sh /dev/null
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 (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; //省略 }
1
1
以上的代码是很危险的，如果将 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);
}
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
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)
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设 MyThread 的 run 函数是一个很费 时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一 般情况下当屏幕转换时会重新创建 Activity，按照我 们的想法，老的 Activity 应该会被销毁才对，然而事实上并非如此。 由于我们的线程是 Activity 的内部类，所以 MyThread 中保存了 Activity 的一个引用，当 MyThread 的 run 函 数没有结束时，MyThread 是不会被销毁的，因此它所引用的老的 Activity 也不会被销毁，因此就出现了内存泄露的 问题。有些人喜欢用 Android 提供的 AsyncTask，但事实上 AsyncTask 的问题更加严重，Thread 只有在 run 函数不结 束时才出现这种内存泄露问题，然而 AsyncTask 内部的实现机制是运用了 ThreadPoolExcutor,该类产生的 Thread 对 象的生命周期是不确定的，是应用程序无法控制的，因此如果 AsyncTask 作为 Activity 的内部类，就更容易出现内存 泄露的问题。
针对这种线程导致的内存泄露问题的解决方案：
第一、将线程的内部类，改为静态内部类（因为非静态内部类拥有外部类对象的强引用，而静态类则不拥有）。
第二、在线程内部采用弱引用保存 Context 引用。
