1、小整数对象池
整数在程序中的使用非常广泛，python 为了优化速度，使用了小整数对象池，避免整数频繁申请和销毁和内存空间。
Python 对小整数的定义事【-5， 257】这些整数对象的hi提前建立好的 ，不会被垃圾回收，在一个 Python 的程序中，所有位于这个范围的整数使用的都是同一个对象。
同理，单个字母也是这样的。
但是当定义2个相同的字符串时，应用计数为0，触发垃圾回收。
2、大整数对象池
每一个大整数对象，均创建一个新的对象。
3、intern 机制
a1 = "HelloWorld" a2 = "HelloWorld" a3 = "HelloWorld" a4 = "HelloWorld" a5 = "HelloWorld" a6 = "HelloWorld" a7 = "HelloWorld" a8 = "HelloWorld" a9 = "HelloWorld
Python 会不会创建 9 个对象呢？
在内存中会不会开辟 9 个 “HelloWorld”的内存空间呢？
想一下？
如果时这样的话，我们写了 10000 个对象，比如 a1 = ‘HelloWorld’ a10000 = ‘HelloWorld’ ,这样的话已不是开辟了 10000 个‘HelloWorld’ 所占的内存空间了呢？
如果真是这样，内存早就爆了，所以 Python 中这样一个机制 ----- intern 机制，让它占用一个 'HelloWorld' 所占的空间，靠引用计数去维护何时释放。
总结：
1、小整数[-5， 257] 共用对象，常驻内存
2、单个字符公用对象，常驻内存
3、单个单词，不可修改，默认开启 intern 机制，共用对象， 引用计数为0， 则销毁
垃圾回收（二）
1、Garbage collection（GC垃圾回收）
现在高级语言如java ，C#等都采用了垃圾回收机制，而不是 c，c++里用户自己管理维护没存的方式，自己管理内存极其自由，可以任意申请内存，但如同一把双刃剑，为大量的内存泄漏，悬空指针埋下了隐患。遂于一个字符串、列表、类甚至数值都是对象，且定位简单易用的怨言，自然不会让用户自己处理如何回收内存的问题，python 里也同 java 一样采用了垃圾回收机制，不过不一样的时：python 采用的时引用计数计数机制为主，标记-消除和分代收集两种机制的策略
引用计数机制：
python里每一个东西都是对象，他们的核心就是一个结构体： PyProject
typedef struct_object{ int ob_refcnt; struct_typeobject *ob_type; } PyProject;
PyProject 是每个对象必有的内容，其中 ob_refcnt就是作为引用计数。当一个随想有新的引用时，他的 ob_refcnt就i会增加，当引用它的对象v欸删除时，它的ob_reflcnt 就会减少；
当引用计数为 0 时，改对象就结束了
引用计数的机制的优点：
1、简单
2、实时性、一旦没有了引用，内存就直接释放了，不用像其他机制等到特定时机，实时性还带来一个好处：处理回收内存的时间分摊到平时
引用计数机制的缺点：
1、维护引用计数消耗资源
2、循环引用
lst1 = [] lst2 = [] lst1.append(lst2) lst2.append(lst1)
lst1和 lst2 相互引用，如果不存在其他对象对他们的引用，lst1与lst2的引用计数也任然为 1，所占用的内存永远无法回收，这将时致命的。对于如今的强大硬件，缺点1尚可接受，但是循环引用导致内存泄漏，注定Python还将引用如夫人回收机制（标记清楚和分代收集）
GC系统所承担的工作远比“垃圾回收”多得多，实际上，他们负责三个重要任务
1、为新生对象分配内存
2、识别那些是垃圾对象
3、从垃圾对象中回收内存
如果将应用程序比作人的身体，所有你写的优雅的代码、业务逻辑，算法，应该就是大脑，依次类推，垃圾回收机制应该是身体的那个器官呢？
腰子没有了人还能活好像 可是对于java、C# 这样的高级语言 没有GC的话 是不是就不行 当然不行 那腰子机制不成立 白血球 嗯也不行 ok 心脏行不行 当然可以 哈哈 如果垃圾回收器停止或者行动迟缓 那内存会不会爆满 会不会 会还不是不会 那好 像动脉阻塞或者心脏停跳 难道不应该是人工呼吸吗 是吗 还有必要吗 哦闹