本文目录一览：
- 1、python为啥运行效率不高
- 2、Python 的内存管理机制
- 3、pythonmemory运行到99%停住了
- 4、BAT面试题28：Python是如何进行内存管理的
- 5、如何让python的GC机制崩溃
- 6、Python的垃圾回收机制原理
python为啥运行效率不高
原因：1、python是动态语言；2、python是解释执行，但是不支持JIT；3、python中一切都是对象，每个对象都需要维护引用计数，增加了额外的工作。4、python GIL；5、垃圾回收。
当我们提到一门编程语言的效率时：通常有两层意思，第一是开发效率，这是对程序员而言，完成编码所需要的时间；另一个是运行效率，这是对计算机而言，完成计算任务所需要的时间。编码效率和运行效率往往是鱼与熊掌的关系，是很难同时兼顾的。不同的语言会有不同的侧重，python语言毫无疑问更在乎编码效率，life is short，we use python。
虽然使用python的编程人员都应该接受其运行效率低的事实，但python在越多越来的领域都有广泛应用，比如科学计算 、web服务器等。程序员当然也希望python能够运算得更快，希望python可以更强大。
首先，python相比其他语言具体有多慢，这个不同场景和测试用例，结果肯定是不一样的。这个网址给出了不同语言在各种case下的性能对比，这一页是python3和C++的对比，下面是两个case：
从上图可以看出，不同的case，python比C++慢了几倍到几十倍。
python运算效率低，具体是什么原因呢，下列罗列一些：
第一：python是动态语言
一个变量所指向对象的类型在运行时才确定，编译器做不了任何预测，也就无从优化。举一个简单的例子： r = a + b。 a和b相加，但a和b的类型在运行时才知道，对于加法操作，不同的类型有不同的处理，所以每次运行的时候都会去判断a和b的类型，然后执行对应的操作。而在静态语言如C++中，编译的时候就确定了运行时的代码。
另外一个例子是属性查找，关于具体的查找顺序在《python属性查找》中有详细介绍。简而言之，访问对象的某个属性是一个非常复杂的过程，而且通过同一个变量访问到的python对象还都可能不一样（参见Lazy property的例子）。而在C语言中，访问属性用对象的地址加上属性的偏移就可以了。
第二：python是解释执行，但是不支持JIT（just in time compiler）。虽然大名鼎鼎的google曾经尝试Unladen Swallow 这个项目，但最终也折了。
第三：python中一切都是对象，每个对象都需要维护引用计数，增加了额外的工作。
第四：python GIL，GIL是Python最为诟病的一点，因为GIL，python中的多线程并不能真正的并发。如果是在IO bound的业务场景，这个问题并不大，但是在CPU BOUND的场景，这就很致命了。所以笔者在工作中使用python多线程的情况并不多，一般都是使用多进程（pre fork），或者在加上协程。即使在单线程，GIL也会带来很大的性能影响，因为python每执行100个opcode（默认，可以通过sys.setcheckinterval()设置）就会尝试线程的切换，具体的源代码在ceval.c::PyEval_EvalFrameEx。
第五：垃圾回收，这个可能是所有具有垃圾回收的编程语言的通病。python采用标记和分代的垃圾回收策略，每次垃圾回收的时候都会中断正在执行的程序，造成所谓的顿卡。infoq上有一篇文章，提到禁用Python的GC机制后，Instagram性能提升了10%。感兴趣的读者可以去细读。
推荐课程：Python机器学习(Mooc礼欣、嵩天教授)
Python 的内存管理机制
Python采用自动内存管理，即Python会自动进行垃圾回收，不需要像C、C++语言一样需要程序员手动释放内存，手动释放可以做到实时性，但是存在内存泄露、空指针等风险。
Python自动垃圾回收也有自己的优点和缺点：优点：
缺点：
Python的垃圾回收机制采用 以引用计数法为主，分代回收为辅 的策略。
先聊引用计数法，Python中每个对象都有一个核心的结构体，如下
一个对象被创建时，引用计数值为1，当一个变量引用一个对象时，该对象的引用计数ob_refcnt就加一，当一个变量不再引用一个对象时，该对象的引用计数ob_refcnt就减一，Python判断是否回收一个对象，会将该对象的引用计数值ob_refcnt减一判断结果是否等于0，如果等于0就回收，如果不等于0就不回收，如下：
一个对象在以下三种情况下引用计数会增加：
一个对象在以下三种情况引用计数会减少：
验证案例：
运行结果：
事实上，关于垃圾回收的测试，最好在终端环境下测试，比如整数257，它在PyCharm中用下面的测试代码打印出来的结果是4，而如果在终端环境下打印出来的结果是2。这是因为终端代表的是原始的Python环境，而PyCharm等IDE做了一些特殊处理，在Python原始环境中，整数缓存的范围是在 [-5, 256] 的双闭合区间内，而PyCharm做了特殊处理之后，PyCharm整数缓存的范围变成了 [-5, 无穷大]，但我们必须以终端的测试结果为主，因为它代表的是原始的Python环境，并且代码最终也都是要发布到终端运行的。
好，那么回到终端，我们来看两种特殊情况
前面学习过了，整数缓存的范围是在 [-5, 256] 之间，这些整数对象在程序加载完全就已经驻留在内存之中，并且直到程序结束退出才会释放占有的内存，测试案例如下：
如果字符串的内容只由字母、数字、下划线构成，那么它只会创建一个对象驻留在内存中，否则，每创建一次都是一个新的对象。
引用计数法有缺陷，它无法解决循环引用问题，即A对象引用了B对象，B对象又引用了A对象，这种情况下，A、B两个对象都无法通过引用计数法来进行回收，有一种解决方法是程序运行结束退出时进行回收，代码如下：
前面讲过，Python垃圾回收机制的策略是 以引用计数法为主，以分代回收为辅 。分代回收就是为了解决循环引用问题的。
Python采用分代来管理对象的生命周期：第0代、第1代、第2代，当一个对象被创建时，会被分配到第一代，默认情况下，当第0代的对象达到700个时，就会对处于第0代的对象进行检测和回收，将存在循环引用的对象释放内存，经过垃圾回收后，第0代中存活的对象会被分配为第1代，同样，当第1代的对象个数达到10个时，也会对第1代的对象进行检测和回收，将存在循环引用的对象释放内存，经过垃圾回收后，第1代中存活的对象会被分配为第2代，同样，当第二代的对象个数达到10个时，也会对第2代的对象进行检测和回收，将存在循环引用的对象释放内存。Python就是通过这样一种策略来解决对象之间的循环引用问题的。
测试案例：
运行结果：
如上面的运行结果，当第一代中对象的个数达到699个即将突破临界值700时（在打印699之前就已经回收了，所以看不到698和699）进行了垃圾回收，回收掉了循环引用的对象。
第一代、第二代、第三代分代回收都是有临界值的，这个临界值可以通过调用 gc.get_threshold 方法查看，如下：
当然，如果对默认临界值不满意，也可以调用 gc.set_threshold 方法来自定义临界值，如下：
最后，简单列出两个gc的其它方法，了解一下，但禁止在程序代码中使用
以上就是对Python垃圾回收的简单介绍，当然，深入研究肯定不止这些内容，目前，了解到这个程度也足够了。
pythonmemory运行到99%停住了
因为遇到MemoryError的问题了。
解决方法。1.回收一些暂时不用的内存。2.修改数据类型的长度。3.读文件的时候可以逐行读取或者分块读取，避免一次性把数据都读入到内存里，导致程序崩掉。4.修改磁盘虚拟内存。
python的psutil包可以查看内存的使用情况，直接点任务管理器也可以查看电脑的内存使用占比，还可以kill掉一些不用的进程来释放内存。但是如果想要释放掉python占用的内存，比如一些使用过后续又不再需要的数据，可以导入gc包直接删除掉数据并回收内存。
BAT面试题28：Python是如何进行内存管理的
Python的内存管理，一般从以下三个方面来说：
1)对象的引用计数机制(四增五减)
2)垃圾回收机制(手动自动，分代回收)
3)内存池机制(大m小p)
1)对象的引用计数机制
要保持追踪内存中的对象，Python使用了引用计数这一简单的技术。sys.getrefcount(a)可以查看a对象的引用计数，但是比正常计数大1，因为调用函数的时候传入a，这会让a的引用计数+1
2)垃圾回收机制
吃太多，总会变胖，Python也是这样。当Python中的对象越来越多，它们将占据越来越大的内存。不过你不用太担心Python的体形，它会在适当的时候“减肥”，启动垃圾回收(garbage
collection)，将没用的对象清除
从基本原理上，当Python的某个对象的引用计数降为0时，说明没有任何引用指向该对象，该对象就成为要被回收的垃圾了
比如某个新建对象，它被分配给某个引用，对象的引用计数变为1。如果引用被删除，对象的引用计数为0，那么该对象就可以被垃圾回收。
然而，减肥是个昂贵而费力的事情。垃圾回收时，Python不能进行其它的任务。频繁的垃圾回收将大大降低Python的工作效率。如果内存中的对象不多，就没有必要总启动垃圾回收。
所以，Python只会在特定条件下，自动启动垃圾回收。当Python运行时，会记录其中分配对象(object
allocation)和取消分配对象(object deallocation)的次数。当两者的差值高于某个阈值时，垃圾回收才会启动。
我们可以通过gc模块的get_threshold()方法，查看该阈值。
3)内存池机制
Python中有分为大内存和小内存：(256K为界限分大小内存)
1、大内存使用malloc进行分配
2、小内存使用内存池进行分配
python中的内存管理机制都有两套实现，一套是针对小对象，就是大小小于256K时，pymalloc会在内存池中申请内存空间;当大于256K时，则会直接执行系统的malloc的行为来申请内存空间。
如何让python的GC机制崩溃
（Memory Leak，内存泄漏）
为什么会产生内存泄漏？
当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。
内存泄漏对程序的影响？
内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。
如何检查和分析内存泄漏？
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。
1、MAT是一款强大的内存分析工具，功能繁多而复杂。
2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。
常见的内存泄漏及解决方法
1、单例造成的内存泄漏
由于单例的静态特性使得其生命周期和应用的生命周期一样长，如果一个对象已经不再需要使用了，而单例对象还持有该对象的引用，就会使得该对象不能被正常回收，从而导致了内存泄漏。
示例：防止单例导致内存泄漏的实例
// 使用了单例模式
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}
这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。？？？
2、非静态内部类创建静态实例造成的内存泄漏
例如，有时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现如下写法：
public class MainActivity extends AppCompatActivity {
private static TestResource mResource = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(mResource == null){
mResource = new TestResource();
}
//...
}
class TestResource {
//...
}
}
这样在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建，但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，从而导致Activity的内存资源不能被正常回收。
解决方法：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
3、Handler造成的内存泄漏
示例：创建匿名内部类的静态对象
public class MainActivity extends AppCompatActivity {
private final Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
@Override
public void run() {
// ...
handler.sendEmptyMessage(0x123);
}
});
}
}
1、从Android的角度
当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。另外，主线程的Looper对象会伴随该应用程序的整个生命周期。
2、 Java角度
在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。
对上述的示例进行分析，当MainActivity结束时，未处理的消息持有handler的引用，而handler又持有它所属的外部类也就是MainActivity的引用。这条引用关系会一直保持直到消息得到处理，这样阻止了MainActivity被垃圾回收器回收，从而造成了内存泄漏。
解决方法：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
4、线程造成的内存泄漏
示例：AsyncTask和Runnable
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();
}
class MyAsyncTask extends AsyncTaskVoid, Void, Void {
// ...
public MyAsyncTask(Context context) {
// ...
}
@Override
protected Void doInBackground(Void... params) {
// ...
return null;
}
@Override
protected void onPostExecute(Void aVoid) {
// ...
}
}
class MyRunnable implements Runnable {
@Override
public void run() {
// ...
}
}
}
AsyncTask和Runnable都使用了匿名内部类，那么它们将持有其所在Activity的隐式引用。如果任务在Activity销毁之前还未完成，那么将导致Activity的内存资源无法被回收，从而造成内存泄漏。
解决方法：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
5、资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。
1）比如在Activity中register了一个BraodcastReceiver，但在Activity结束后没有unregister该BraodcastReceiver。
2）资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄漏。
3）对于资源性对象在不使用的时候，应该调用它的close()函数将其关闭掉，然后再设置为null。在我们的程序退出时一定要确保我们的资源性对象已经关闭。
4）Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了。
6、使用ListView时造成的内存泄漏
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。
构造Adapter时，没有使用缓存的convertView。
解决方法：在构造Adapter时，使用缓存的convertView。
7、集合容器中的内存泄露
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
解决方法：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
8、WebView造成的泄露
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。
解决方法：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
如何避免内存泄漏？
1、在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：
其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。
2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。
3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。
4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。
5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：
1）将内部类改为静态内部类
2）静态内部类中使用弱引用来引用外部类的成员变量
Python的垃圾回收机制原理
1.Python的垃圾回收机制原理
Python无需我们手动回收内存，它的垃圾回收是如何实现的呢？
引用计数为主（缺点：循环引用无法解决）
引入标记清除和分代回收解决引用计数问题
引用计数为主+标记清除和分代回收为辅
垃圾回收（GC）
（1）引用计数
a = [1] # [1]对象引用计数增加1，ref=1
b = a # [1]对象引用计数增加1，ref=2
b = None # [1]对象引用计数减少1，ref=1
del a # [1]对象引用计数减少1，ref=0
a = [1],当把列表 [1] 赋值给 a 的时候，它的引用计数就会增加1，此时列表 [1] 对象的引用计数ref=1 ； b = a 又把 a 赋值给 b ，a和b 同时引用了列表[1]对象，ref又增加1，此时 ref =2。继续执行 b = None， 让b指向None，这个时候它就不会指向原来的列表[1]对象，列表[1]对象的引入计数就会减少1，又变成ref=1。执行del a ，引用计数就会减少1，这个时候 ref = 0。当对象的引用计数为0就可以回收掉，
注意：del 作用就会减少对象引用计数，并不是销毁对象。只有当引用计数为0的时候，Python解释器才回去把对象占用的内存回收掉。
// object.h
struct _object {
Py_ssize_t ob_refcnt; # 引用计数值
}PyObject;
① 什么时候引用计数增加呢？
② 什么时候引用计数会减少呢？
（2）引用计数无法解决循环引用问题
循环引用
a = [1] # 对象[1]引用计数增加1，ref=1
b = [2] # 对象[2]引用计数增加1，ref=1
a.append(b) # b被a引用，对象[2]引用计数增加1，ref=2
b.append(a) # a又被b引用，对象[1]引用计数增加1，ref=2
del a # 对象[1]引用计数减少1，ref=1
del b # 对象[2]引用计数减少1，ref=1
（3）标记清除（Mark and Sweep）
（4）分代回收
import gc
