内存泄漏&指针悬挂&野指针
内存泄漏： 动态申请的内存 没释放
中虽然有内存管理机制，但也存在内存泄漏
悬挂指针（迷途指针）野指针：&(这两个概念很相似)
1、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的默认值是随机的，它会乱指一气。
2、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。
3、指针操作超越了变量的作用范围。这种情况让人防不胜防。（例如函数返回局部指针）
正确使用指针
&通常避免野指针的办法是正确的使用指针&&&
1.声明一个pointer的时候注意初始化为null ：
int* & pInt & =
2.分配完内存以后注意ASSERT：
pInt & = & new &
int[num];&&&
ASSERT(pInt & != &
3. 删除时候注意用对操作符：
int类型的，用delete&&&
对于new & int[]类型的，用delete &
4.删除完毕以后记得给他null地址： &&
delete & [] &
pInt & = &
5.记住，谁分配的 谁回收，不要再一个函数里面分配local &
pointer，送到另外一个函数去delete。
6.返回local & address是非常危险的，如必须这样做，请写注释到程序里面，免得忘记。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。C语言（25）
　用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元，不能被任何程序再次使用，直到程序结束。即所谓内存泄漏。
& &注意：内存泄漏是指堆内存的泄漏。
　简单的说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。由程序申请的一块内存，且没有任何一个指针指向它，那么这块内存就泄露了。
　　“野指针”不是NULL指针，是未初始化或未清零的指针，他指向的内存地址不是程序员想要的。人们一般不会错用NULL指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。野指针的成因主要有两种：
　　一、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。
　　二、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。别看free和delete的名字恶狠狠的（尤其是delete），它们只是把指针所指的内存给释放掉，但并没有把指针本身干掉。通常会用语句if (p != NULL)进行防错处理。很遗憾，此时if语句起不到防错作用，因为即便p不是NULL指针，它也不指向合法的内存块。例：
free()释放的是指针指向的内存！注意！释放的是内存，不是指针！这点非常非常重要！指针是一个变量，只有程序结束时才被销毁。释放了内存空间后，原来指向这块空间的指针还是存在！只不过现在指针指向的内容的垃圾，是未定义的，所以说是垃圾。因此，前面我已经说过了，释放内存后把指针指向NULL，防止指针在后面不小心又被解引用了。非常重要啊这一点！
　　在使用指针的时候还要注意的问题：
　　1：不要返回指向栈内存的指针或引用，因为栈内存在函数结束时会被释放.
& & & 2: &在使用指针进行内存操作前记得要先给指针分配一个动态内存。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：14224次
排名：千里之外
原创：61篇
转载：29篇
(1)(26)(29)(6)(3)(1)(5)(6)(15)linux C开发（50）
　用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。即所谓内存泄漏。
& &注意：内存泄漏是指堆内存的泄漏。
　简单的说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。由程序申请的一块内存，且没有任何一个指针指向它，那么这块内存就泄露了。
　　“野指针”不是NULL指针，是指向“垃圾”内存的指针。人们一般不会错用NULL指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。野指针的成因主要有两种：
　　一、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。
　　二、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。别看free和delete的名字恶狠狠的（尤其是delete），它们只是把指针所指的内存给释放掉，但并没有把指针本身干掉。通常会用语句if (p != NULL)进行防错处理。很遗憾，此时if语句起不到防错作用，因为即便p不是NULL指针，它也不指向合法的内存块。例：
#include&stdio.h&
#include&stdlib.h&
int main()
char *p=(char *)malloc(sizeof(char)*<span style="color:#0);
strcpy(p, “hello”);
printf(“%s ”,p);
9 　free(p); // p 所指的内存被释放，但是p所指的地址仍然不变
<span style="color:# 　if(p != NULL) // 没有起到防错作用
<span style="color:#
strcpy(p, “world”); // 出错
<span style="color:#
printf(“%s \n”,p);
<span style="color:# }
free()释放的是指针指向的内存！注意！释放的是内存，不是指针！这点非常非常重要！指针是一个变量，只有程序结束时才被销毁。释放了内存空间后，原来指向这块空间的指针还是存在！只不过现在指针指向的内容的垃圾，是未定义的，所以说是垃圾。因此，前面我已经说过了，释放内存后把指针指向NULL，防止指针在后面不小心又被解引用了。非常重要啊这一点！
　　在使用指针的时候还要注意的问题：
　　1：不要返回指向栈内存的指针或引用，因为栈内存在函数结束时会被释放.
& & & 2: &在使用指针进行内存操作前记得要先给指针分配一个动态内存。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：24828次
排名：千里之外
原创：34篇
转载：77篇
(2)(2)(2)(3)(2)(1)(2)(5)(5)(10)(1)(4)(2)(1)(4)(10)(1)(11)(1)(1)(1)(2)(38)　　尽管C++ 野指针和内存泄漏一直被诟病，但是在实时性很强的应用场合，c++ 仍然是不二之选。游戏服务器开发仍然使用c++ 作为主语言，但是大多结合动态脚本技术，一方面规避了野指针和内存泄露，一方面获得了开发效率和扩展性的红利。但脚本技术不是本文的讨论重点，事实上关于c++ 与 lua的技术文章我也一直在整理中，将会另文别述。今天主要说说在使用c++过程中，如何避免和解决野指针和内存泄漏问题。
　　野指针的出现会导致程序崩溃，这是每个人都不愿意看到的。Linux会生成coredump文件，可用gdb分析。Win下可以注册unexception获取调用堆栈，将错误信息写到文件中。先分析一下通常出现野指针的场景：
class monster_t
protected:
player_t* m_
void handle_ai()
if (m_attack)
int x = m_attack-&get_x();
　　问题就在于，m_attack有值，但是对应的对象已经被销毁了。这是大部分野指针出现原因。分析类之间关系可知，monster_t 和 player_t是0-1的关系，monster_t引用player_t，但是player_t甚至都不知道有一个（或N个）monster 引用了自己。所以当player被销毁时，很难做到把所有引用该player_t的地方全部重置。这种问题其实比较常见，比如player中引用connection，而connection又是被网络层管理生命周期的，也同样容易产生野指针情况。常见的解决方式是：
class monster_t
protected:
long m_attack_
void handle_ai()
player_t* attack = obj_mgr.get(m_attack_id);
if (attack)
int x = attack-&get_x();
另外一种与之相似的方式：
class monster_t
protected:
player_t* m_
void handle_ai()
if (obj_mgr.is_exist(m_attack))
int x = m_attack-&get_x();
m_attack = NULL;
　　梳理野指针的产生原因后，我们其实需要的是这样的指针：
　　一种指针，引用了另一个对象的地址（不然就不是指针了），当目标对象销毁时，该指针自然指向null，而不需要目标对象主动通知重置。
幸运的是，这种指针已经有了，就是weak_ 在boost库中，sharedptr,scopedptr,weakptr统称为smartptr。可以尽量使用智能指针，避免野指针。本人建议尽量使用shared_ptr结合weak_ptr使用。Scoped_ptr本人使用的较少，只是在创建线程对象的时候使用，正好符合不能复制的语义。使用shared_ptr和weak_ptr的示例代码：
class monster_t
protected:
weak_ptr&player_t& m_
shared_ptr&player_t& get_attack()
return shared_ptr&player_t&(m_attack);
void handle_ai()
shared_ptr&player_t& attack = get_attack();
if (attack)
int x = attack-&get_x();
有人问monster_t为什么不直接使用shared_ptr，如果使用shared_ptr就不符合现实的模型了，monster_t显然不应该控制player_t的生命周期，如果使用了shared_ptr，那么可能导致player_t被延迟析构，甚至会导致内存暴涨。这也是shared_ptr的使用误区，所以本人建议尽量shared_ptr和weak_ptr结合用，否则野指针问题解决了，内存泄漏问题又来了。
内存泄漏：
野指针问题可以通过采用良好的编程范式，尽量规避，但总计c++规避内存泄漏的方法却很为难，简单而言尽量保证对象的分配和释放（分别）是单个入口的，这样大部分问题都可以拦截在code review阶段。那么怎么检测内存泄漏呢？
首先说明本方法区别于valgrind等工具，该工具是调试期进行的检测，本文探究的是运行期的检测，确切说是运行期定时输出所有对象的数量到日志中。
首先定义分配、释放对象的接口：
template&typename T&
T* new_obj()
T* p = new T();
singleton_t&obj_counter_t&T& &::instance().inc(1);
template&typename T, typename ARG1&
T* new_obj(ARG1 arg1)
T* p = new T(arg1);
singleton_t&obj_counter_t&T& &::instance().inc(1);
template&typename T, typename ARG1, typename ARG2&
T* new_obj(ARG1 arg1, ARG2 arg2)
T* p = new T(arg1, arg2);
singleton_t&obj_counter_t&T& &::instance().inc(1);
template&typename T&
T* new_array(int n)
T* p = new T[n];
singleton_t&obj_counter_t&T& &::instance().inc(n);
为了节省篇幅，这里只列举了三种构造的代码，当分配对象时，对应的类型数量增加1，obj_counter 使用原子操作为每一种类型记录其数量。
class obj_counter_i
obj_counter_i():m_ref_count(0){}
virtual ~ obj_counter_i(){}
void inc(int n) { (void)__sync_add_and_fetch(&m_ref_count, n); }
void dec(int n) { __sync_sub_and_fetch(&m_ref_count, n);
long val() const{ return m_ref_
virtual string get_name() { return ""; }
protected:
volatile long m_ref_
template&typename T&
class obj_counter_t: public obj_counter_i
obj_counter_t()
singleton_t&obj_counter_t&T& &::instance().reg(this);
virtual string get_name() { return TYPE_NAME(T); }
相应的当对象被释放的时候，对应的对象数量减一，示例代码如下：
template&typename T&
void del_obj(T* p)
singleton_t&obj_counter_t&T& &::instance().dec(1);
这样就做到了所有的对象的数量都被记录了，可以定时的将对象数量输出到文件：
class obj_counter_summary_t
void reg(obj_counter_i* p)
m_all_counter.push_back(p);
map&string, long& get_all_obj_num()
map&string, long&
for (list&obj_counter_i*&::iterator it = m_all_counter.begin(); it != m_all_counter.end(); ++it)
ret.insert(make_pair((*it)-&get_name(), (*it)-&val()));
void dump(const string& path_)
ofstream tmp_
tmp_fstream.open(path_.c_str());
map&string, long& ret = get_all_obj_num();
map&string, long&::iterator it = ret.begin();
time_t timep
= time(NULL);
struct tm *tmp = localtime(&timep);
char tmp_buff[256];
sprintf(tmp_buff, "%04d%02d%02d-%02d:%02d:%02d",
tmp-&tm_year + 1900, tmp-&tm_mon + 1, tmp-&tm_mday,
tmp-&tm_hour, tmp-&tm_min, tmp-&tm_sec);
char buff[1024] = {0};
snprintf(buff, sizeof(buff), "obj,num,%s\n", tmp_buff);
tmp_fstream &&
for (; it != ret.end(); ++it)
snprintf(buff, sizeof(buff), "%s,%ld\n", it-&first.c_str(), it-&second);
tmp_fstream &&
tmp_fstream.flush();
protected:
list&obj_counter_i*&
输出的文件格式为csv格式，方便进一步做数据分析。可以使用我开发的小工具格式化csv数据。url:
文件内容data:
obj,num,:01:41dumy,1111foo,222obj,num,:01:41dumy,11311foo,2422obj,num,:01:41dumy,41111foo,24442
野指针可以使用shared_ptr和weak_ptr结合使用来尽量规避。
使用shared_ptr要尽量小心，否则可能导致对象无法释放，导致内存泄漏。
可以定时输出当前所有对象的数量，来分析是否有内存泄漏，或者内存泄漏是有哪些对象引起的。
本文介绍了记录所有对象的方法，除了可以分析内存泄漏外，也不失为数据分析的一种方法。需要注明的是，本方法不能替代valgrind工具，二者作用不同。
TYPE_NAME 的实现参考
& & 全部示例代码：obj_tool.h
阅读(...) 评论()今日科技快讯
上海市网信办会同市文广局、市网安总队、市文化执法总队，就直播中的低俗色情问题依法联合约谈熊猫直播和全民直播，要求上述直播网站进行全面整改。熊猫直播方面表示，此次整改主要是一些弹幕的问题，而非直播内容问题，后续会进行一套配合工作，总体会围绕弹幕氛围的引导来做。
本篇是&南尘&的第二篇投稿，全方位分析了导致内存泄漏的原因，并给出解决方案。希望能够帮助到大家。
南尘&的博客地址：
/liushilin
对于 C++ 来说，内存泄漏就是new出来的对象没有 delete，俗称野指针；而对于 java 来说，就是 new 出来的 Object 放在 Heap 上无法被GC回收；而这里就把我之前的一篇内存泄漏的总结翻新，做一个更加全面规范的讲解，希望能帮到各位。
java的内存分配
静态存储区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量；
栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存；
堆区：通常用来存放new出来的对象。由java垃圾回收期回收。
四种引用类型的介绍
强引用(StrongReference)：JVM 宁可抛出 OOM ，也不会让 GC 回收具有强引用的对象；
软引用(SoftReference)：只有在内存空间不足时，才会被回的对象；
弱引用(WeakReference)：在 GC 时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存；
虚引用(PhantomReference)：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否存在该对象的虚引用，来了解这个对象是否将要被回收。可以用来作为GC回收Object的标志。
这样的图很熟悉有木有？当这样的时候，说明你的内存真的在变少了。
内存泄漏检测工具
1.&MAT(Memory Analyzer Tool)，下载地址：
http://www.eclipse.org/mat/downloads.php
具体使用这个网上一大篇，楼主一有时间也会为大家一步步奉上。
2.&强大的开源内存检测工具 LeakCanary。
leakcanary 是一个开源项目，一个内存泄露自动检测工具，是著名的 GitHub 开源组织 Square 贡献的，它的主要优势就在于自动化过早的发觉内存泄露、配置简单、抓取贴心，缺点在于还存在一些bug，不过正常使用百分之九十情况是OK的，其核心原理与MAT工具类似。
因为配置十分简单，只需要几句话就好！！！这里就不多说了，大家可以看官方文档：
/square/leakcanary
内存泄漏解析
永远的Singleton
单例的使用在我们的程序中随处可见，因为使用它可以完美的解决我们在程序中重复创建对象的问题，不过可别小瞧它。由于单例的静态特性，使得它的生命周期和应用的生命周期会一样长，所以一旦使用有误，小心无限制的持有Activity的引用而导致内存泄漏。比如，下面的例子。
这个错误在生活中再普遍不过，很正常的一个单例模式，可就由于传入的是一个 Context，而这个 Context 的生命周期的长短就尤为重要了。如果我们传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出的时候，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会回收，这造成的内存泄漏就可想而知了。
正确的方式应该是把传入的 Context 换为和应用的生命周期一样长的 Application 的 Context：
当然，你也可以直接连 Context 都不用传入了。重写 application，提供静态的 getContext 方法：
自然就可以直接不用传入Context:
令人心塞的Handler
这个东西在我最近遇到的最多了，而它也是我们在内存泄漏中最为常见的，也许你的一个小忽略就会导致内存泄漏。在Android的新版本中，我们被要求必须把网络任务等耗时操作置于新线程来处理，我们通常会采用 Handler。
但 Handler 不是万能的，若是我们的编写不规范就有可能会造成内存泄漏。另外，我们知道，Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将会被线程 MessageQueue 一直持有。
由于 Handler 属于 TLS（Thread Local Storage）变量，生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期一致，故很容易导致无法正确释放。比如：
在例子中，我们申明了一个&延迟5分钟&执行的消息 Message。当该 Activity 被 finish 的时候，延迟任务的 Message 还存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish 掉的 Activity 就不会回收了，所以造成了内存泄漏（因 handler 为非静态内部类，它会持有外部类的引用，在这里就是当前的 Activity）。
修复：这个解决也是可以通过把其声明为 static 的，则其存活期就跟 activity 的生命周期无关了。不过倘若用到 Context 等外部类的 非static 对象，还是应该通过弱引用传入。比如：
综述：推荐使用静态内部类+弱引用 WeakReference 这种方式，但要注意每次使用前判空。
说到若引用，这里再提下java的几种引用类型：Strong, reference,SoftReference,WeakReference 和 PhatomReference:
在 Android 开发中，为了防止内存溢出，在处理一些占用内存大并且生命周期较长的对象的时候，可以尽量地使用 软引用 和 弱引用 技术。
比如，保存 Bitmap 的软引用到 HashMap:
使用软引用以后，在 OutOfMemory 异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。
如果只是想避免 OutOfMemory 异常的发生，则可以使用 软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用 弱引用。
另外可以根据对象是否经常使用来判断选择 软引用 还是 弱引用。如果该对象可能会经常使用的，就尽量用 软引用。如果该对象不被使用的可能性更大些，就可以用 弱引用。
ok，继续回到主题。前面所说的，创建一个 静态Handler内部类，然后对 Handler 持有的对象使用弱引用，这样在回收时也可以回收 Handler 持有的对象，但是这样做虽然避免了 Activity 泄漏，不过 Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。
下面几个方法都可以移除 Message：
匿名内部类/非静态内部类
它们方便却暗藏杀机。Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果你使用了匿名类，而又被异步线程所引用，那得小心，如果没有任何措施同样会导致内存泄漏的：
runnable1&和&runnable2&的区别就是，runnable2 使用了匿名内部类，我们看看引用时的引用内存：
可以看到，runnable1 是没有什么特别的。但 runnable2 多出了一个 MainActivity 的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。
前辈箴言——善用static成员变量
前面就很明显，当我们的成员变量是&static&的时候，那么它的生命周期将和整个app的生命周期一致。
这必然会导致一系列问题，如果你的app进程设计上是长驻内存的，那即使app切到后台，这部分内存也不会被释放。按照现在手机app内存管理机制，占内存较大的后台进程将优先回收，因为如果此app做过进程互保保活，那会造成app在后台频繁重启。当手机安装了你参与开发的app以后一夜时间手机被消耗空了电量、流量，你的app不得不被用户卸载或者静默。
这里修复的方法是：
不要在类初始时初始化静态成员。可以考虑 lazy初始化（延迟加载）。架构设计上要思考是否真的有必要这样做，尽量避免。如果架构需要这么设计，那么此对象的生命周期你有责任管理起来。
远离非静态内部类和匿名类，多用private static class
在我们的日常代码中，这样的情况似乎很常见，及直接写一个class就这么光秃秃的情况。
这样就在 Activity 内部创建了一个非静态内部类的单例，每次启动 Activity 时都会使用该单例的数据，这样虽然避免了资源的重复创建，不过这种写法却会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该 Activity 的引用，导致 Activity 的内存资源不能正常回收。正确的做法为：
将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用 Context，请按照上面推荐的使用 Application 的 Context。当然，Application 的 context &不是万能的，所以也不能随便乱用，对于有些地方则必须使用 Activity 的 Context，对于Application，Service，Activity三者的 Context 的应用场景如下：
其中： NO1 表示 Application 和 Service 可以启动一个 Activity，不过需要创建一个新的 task 任务队列。而对于 Dialog 而言，只有在 Activity 中才能创建。
集合对象善清除，以免内存泄漏触不及防
我们通常会把一些对象的引用加入到集合容器（比如 ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是 static 的话，那情况就更严重了。
所以在退出程序之前，将集合里面的东西 clear，然后置为 null，再退出程序，如下：
webView虽火，内存泄漏却也火的其所
当我们不再需要使用 webView 的时候，应该调用它的 destory() 方法来销毁它，并释放其占用的内存，否则其占用的内存长期也不能回收，从而造成内存泄漏。
解决方案：为 webView 开启另外一个进程，通过AIDL与主线程进行通信，webView 所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
而另外一些诸如 listView 的 Adapter 没有缓存之类的这里就不再多提了。
做一个小的总结
构造 Adapter 时，没有使用缓存的 convertView
Bitmap 对象不在使用时调用 recycle() 释放内存
Context 使用不当造成内存泄露：不要对一个 Activity Context 保持长生命周期的引用。尽量在一切可以使用应用 ApplicationContext 代替 Context 的地方进行替换。
非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
警惕线程未终止造成的内存泄露；譬如在 Activity 中关联了一个生命周期超过 Activity 的 Thread，在退出 Activity 时切记结束线程。一个典型的例子就是 HandlerThread 的 run 方法是一个死循环，它不会自己结束，线程的生命周期超过了 Activity 生命周期，我们必须手动在Activity的销毁方法中中调运 thread.getLooper().quit(); 才不会泄露。
对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
创建与关闭没有成对出现造成的泄露；譬如 Cursor 资源必须手动关闭，WebView 必须手动销毁，流等对象必须手动关闭等。
不要在执行频率很高的方法或者循环中创建对象（比如onmeasure），可以使用 HashTable 等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放。
真相只有一个
内存泄漏实在太普遍了，真是防不胜防。不过我想告诉广大的小伙伴，程序员嘛，谁还不踩个坑，跳出来，拍拍身上的灰尘，总结一下，过两天又是一条帮帮的coder。你可以的。
每天学习累了，看些搞笑的段子放松一下吧。关注最具娱乐精神的公众号，每天都有好心情。
如果你有好的技术文章想和大家分享，欢迎向我的公众号投稿，投稿具体细节请在公众号主页点击“投稿”菜单查看。
欢迎长按下图&-&&识别图中二维码或者扫一扫关注我的公众号：
我去，本来今天想抢一下沙发呢，我这刚推送过来下面就七八个评论的了！所以我我总结:能否抢到沙发，运气很重要，真真切切如找工作！但前提条件是你要时时刻刻去关注他们，想着他们，才有可能找到好工作，抢到第一！
其实吧，抢第一是有技术手段的，我以后可能会写篇文章来教大家怎么抢
早，今日第一
怪就怪在我同事他在等地铁，所以他第一，而我在地铁上，信号不那么好，要不我第一啊，郭神
邓焦是你同事么，他天天都来抢第一
郭神，早！可以推荐两本深入学习的书吗？
就看群英传和艺术探索这两本吧
抢什么第一，做好笔记
作者给出的单例的demo是非线程安全的。另外我还有一个疑问，作者说的内存分配，四种引用类型都是JVM中的概念，那么在Android的DVM、ART虚拟机中这些机制是否还是一致？如果一致，可以从哪里得到验证？
虽然不是第一，但也是前排啊
是的，每天我俩都是坐在一起的，每天八点他都在惠新西街南口站等换乘，而此时&我已经快到海淀黄庄的公司了，哈哈，他每天都发三个字，而我每天都是在地铁上收到一直看到公司！不想跟他抢第一
早上好，虽然学习计算机， 但是仍需努力进取，
弱引用在安卓中早就不支持了吧！这个文章难道是三年前的？
弱引用不支持了？还真不知道
早早早。。。
总结得很好
前排都是没看文章直奔评论区的…
地铁上，刚看完鸿神的，再看郭神的
内存泄露，还真是一个没有注意的重要问题！
竟然不是第一
webView一直是隐藏的泄漏大户
今天我前排就坐
第二天工作，起太早在车上睡着了！累
早，请叫我第一
bitmap早就不用调用回收了吧？存放的位置已经被Google改变了吧？
好好看完了
记得看过谷歌官方的一篇文章，推荐使用lru算法做缓存，忘了是从那个api版本开始，弱引用几乎起不到什么作用的！
以前用handler直接注解@SuppressLink(Handlerleak)解决报警问题，现在知道为啥了！
以上留言由公众号筛选后显示
阅读(...) 评论()