【Java】Java中内存泄露的场景

在这里呢 ，如果面试官问你Java是否会存在内存泄漏呢 ，一定要回答 ，是的 。但是面试官他马上就会问道： 那你给我列举几个内存泄露的场景吧，
这个时候， 很多有经验的程序员， 他都无法准确的回答 ，这里我给大家准备了一些经典的内存泄露场景。

首先 ，内存泄漏是指一个不再需要被程序使用的对象或者变量还在内存中占有着它的空间， 在c或者c++语言中， 内存的分配和释放是由开发人员手动操作的， 如果程序员忘记了释放， 那么就会造成内存泄露。
但是呢， Java在引入垃圾回收机制的时候， 由垃圾回收器自动的回收， 那么可以极大程度上降低程序员这方面的工作。 但是这并不意味着Java不会出现内存泄露的场景。

在前面的例子，【Java】浅谈Java的垃圾回收(GC)及常用的垃圾回收算法我给大家讲解过， 对于垃圾回收来说， 他的一个判断标准就是这个对象是否可达 ，如果对象可达， 则代表不能被垃圾回收； 如果不可达 则代表可以被回收。

基于这个标准， 我们总结出来一些由于我们人为失误所造成的内存泄露情况。

首先呢 ，第一种场景叫做静态集合类。
对于有些程序员 他特别喜欢用static静态关键字来描述对象或者是变量， 这种做法是非常有问题的 ，因为对于静态的对象来说 ，它存储在我们的方法区中 ，作为垃圾回收器 ，几乎不会对方法区里边的东西进行高频度的回收， 那么，如果在这里你用static描述了一个集合， 而存放的数据量就比较大， 比如你把整个公司全年的财务信息都放在里面去， 或者你把这些中国的什么什么省份的 ，财政数据放进去， 那么必然会造成这些数据无法被及时的回收以及内存释放， 久而久之， 数据一点点堆积。 而我们的方法区的内存往往来说是比较小的， 到时候就会产生内存溢出的情况， 进而程序崩溃 。

第二种呢 叫做 各种连接
实际开发的时候 比如说像数据库连接， 网络连接， io的连接等等等等。 我们只知道把它打开 ，但忘记把它关闭， 碰到这种情况 ，因为我们的连接被显式的打开了， 但没有关闭 ，所以 ，在JVM中， 这些对象一直是可达的， 因此他不会被回收 ，久而久之， 连接再堆砌就导致了程序崩溃。

第三种叫做监听器
在Java语言中， 往往呢会使用到监听器 ，一个应用可能会使用到多个监听器。 比如说， 在我们Java Web中有底层的网络监听器listener ，监听器的作用就是去监听指定的类或者对象他产生的行为 ，从而做出对应的响应， 因为监听器往往都是全局存在的， 如果对于监听器中所使用这些对象或者是变量 ，你没有有效的控制的话 ，很容易产生内存泄露 。

第四种叫做不合理的作用域
在我们软件开发 ，有一个基本原则叫做作用域最小化 。如果这个变量能声明在方法中， 就不要把它打到方法外 。能用private， 不要用public。 在我们平时使用的时候 ，作用域正确使用是一个Java工程师的基本功 ，我们只有需要用它的时候才去创建它， 那么， 如果一个变量的定义范围大于它的使用范围 很可能就会造成内存泄漏的情况 。

另外呢， 如果在我们平时使用时没有把引用的对象及时设置为null的话 ，也有可能会造成内存泄漏的产生 ，不过这种情况是极少发生的。