理解Java类加载器之静态变量总结

Android是用Java开发，其静态变量的生命周期遵守Java的设计。静态变量是在类被load的时候分配内存的，并且存在于方法区。当类被卸载的时候，静态变量被销毁。在PC机的客户端程序中，一个类被加载和卸载，可简单的等同于jvm进程的启动和结束。那么在Android中呢？用的Dalvik vm也是一样的。不过Android不太突出的进程概念，所以对静态变量的生命周期就会感觉模糊，这种模糊对于值类型是无所谓的，如果是静态的对象引用，则与内存回收、内存泄漏这些问题有关，有必要加深研究和理解。

一、静态变量在类被加载的时候分配内存。

类在什么时候被加载？

当我们启动一个app的时候，系统会创建一个进程，此进程会加载一个Dalvik VM的实例，然后代码就运行在DVM之上，类的加载和卸载，垃圾回收等事情都由DVM负责。也就是说在进程启动的时候，类被加载，静态变量被分配内存。

二、静态变量在类被卸载的时候销毁。

类在什么时候被卸载？

在进程结束的时候。

说明：一般情况下，所有的类都是默认的ClassLoader加载的，只要ClassLoader存在，类就不会被卸载，而默认的ClassLoader生命周期是与进程一致的，本文讨论一般情况。

三、Android中的进程什么时候结束

这个是Android对进程和内存管理不同于PC的核心——如果资源足够，Android不会杀掉任何进程，另一个意思就是进程随时可能会被杀掉。而Android会在资源够的时候，重启被杀掉的进程。也就是说静态变量的值，如果不做处理，是不可靠的，可以说内存中的一切都不可靠。如果要可靠，还是得保存到Nand或SD卡中去，在重启的时候恢复回来。

另一种情况就是不能把退出所有Activity等同于进程的退出，所以在用户点击图标启动应用的时候，以前存放于静态变量中的值，有可能还存在，因此要视具体情况给予清空操作。

四、Application也是一样不可靠

Application其实是一个单例对象，也是放在内存中的，当进程被杀掉，就全清空了，只不过Android系统会帮重建Application，而我们存放在Application的数据自然就没有了，还是得自己处理。

五、静态引用的对象不会被垃圾回收

只要静态变量没有被销毁也没有置null，其对象一直被保持引用，也即引用计数不可能是0，因此不会被垃圾回收。因此，单例对象在运行时不会被回收。

static修饰的静态变量，在不同的类和包中都可以使用，在虚拟机中单独占用内存，但是可能会出现NullException的异常。 
static访问是无法跨进程的。Android中的Activity，Service是可以在各自进程中运行的，用static传递参数到不同进程的Activity、Service时会错。 
static占据的那份内存，在接个电话或者长时间待机后，再回到应用也会出现崩溃的现象，而这些崩溃都与静态变量的空指针有关系。 
根据Google官方的推荐，我们应该尽量使用继承自Application的自定义类，在我们继承的类中定义需要全局使用的变量，并通过getApplicationContext()来获取和保存相关的变量即可。 
启动Application时，系统会创建一个PID，即进程ID，所有的Activity就会在此进程上运行。那么我们在Application创建的时候初始化全局变量，同一个应用的所有Activity都可以取到这些全局变量的值，换句话说，我们在某一个Activity中改变了这些全局变量的值，那么在同一个应用的其他Activity中值就会改变。 
如果想在整个应用中使用全局变量，在java中一般是使用静态变量，public类型；而在android中如果使用这样的全局变量就不符合Android的框架架构，但是可以使用一种更优雅的方式就是使用Application context。 

前段时间公司测试人员告诉我，在测试机上有段时间没运行的app再去测试的时候突然崩溃了。

事实上再次启动程序之后，这个问题就不存在了，一切都是那么正常，但是这种莫名其妙的bug怎么可以放任它存在了，最后也是一顿折腾总算是找到了原因，看到标题应该有人明白怎么回事了，就是static，现在就在这里好好说说。

static 修饰的静态变量，在不同的类和包中都可以使用，系统为我们app创建虚拟机之后，类被加载，静态变量被分配内存，并且在虚拟机中单独占用内存，静态变量在类被卸载的时候才会被销毁，而类只有在进程结束的时候才会被卸载，也就是说被static修饰的静态变量只有在进程被销毁的时候才会被回收 。在我之前的概念里，一个app进程只有被主动退出或者主动清理后才会被销毁，但是事实上，android 系统在资源不足的情况下就会kill掉进程已保证系统正常运行，通常情况下会优先kill掉进程优先级比较低的进程，例如处于后台长时间没有运行的进程，但系统在内存极少的情况下，依然会选择kill 掉一些前台进程，系统kill进程顺序：后台进程 -> 服务进程 -> 可见进程 -> 前台进程。说道这里，也就可以解释我程序为什么会崩溃的原因了：在我进入某一特定界面activityA之前，会给某一static静态变量B赋值，这样在activityA我就可以使用B来进行一些逻辑操作，但是在某一未知时间，系统由于资源紧张而kill掉我的进程，然后在资源充足的情况重新恢复了进程恢复了activityA，造成了当前进程未被kill掉的假象，由于进程被重新创建，原来被赋值的静态变量B被重置，那么在我操作B的时候由于没有做空值检测，抛出空指针，so , game over…

详情可以参考：

http://zmywly8866.github.io/2014/12/26/android-do-not-store-data-in-the-application-object.html

http://www.cnblogs.com/meizixiong/p/4493171.html

http://blog.sina.com.cn/s/blog_476d58ef0102vz2n.html

http://blog.csdn.net/nokiaguy/article/details/5998986

找到了原因那么就说说解决办法：

1. 尽量少使用static来修饰变量，尤其是一些关键性的数据，并且对于被修饰过的变量在使用前要进行空值检测；

2. 对于一些重要信息，可以选择本地持久化

3. 善用onSaveInstanceState及onRestoreInstanceState方法对数据进行保存和恢复，当然在oncreat方法里我们也可以使用savedInstanceState对数据进行恢复，

关于onSaveInstanceState及onRestoreInstanceState被调用的时机：

onRestoreInstanceState方法在onStart之后被调用，此时可以进行数据恢复（前提是有进行了数据保存操作）； 
onSaveInstanceState方法在onPause之后被调用； 
注意：系统只在Activity异常终止的时候才会调用onSaveInstanceState与onRestoreInstanceState来储存和恢复数据，其他情况不会触发这个过程。但是按Home键或者启动新Activity仍然会单独触发onSaveInstanceState的调用

 参考：https://blog.csdn.net/ithouse/article/details/53319589

https://blog.csdn.net/zhoudaxia/article/details/35824249

https://www.cnblogs.com/hf-cherish/p/4970267.html