hashCode竟然不是根据对象内存地址生成的？还对内存泄漏与偏向锁有影响？

起因

起因是群里的一位童鞋突然问了这么问题：

如果重写 equals 不重写 hashcode 会有什么影响？

这个问题从上午10:45 开始陆续讨论，到下午15:39 接近尾声 （忽略这形同虚设的马赛克）

这是一个好问题，更是一个高频基础面试题，我还曾经专门写过一篇文章 Java equals 和 hashCode 的这几个问题可以说明白吗, 主要说明了以下内容

随着讨论的进行，问题慢慢集中在内存溢出和内存泄漏的问题上

内存溢出 VS 内存泄漏

这两个词在中文解释上有些相似，至少给我的第一感觉，他们的差别是这样的（有人和我一样吗？）

内存溢出：Out of Memory (OOM) ，这个大家都很熟悉了，理解起来也很简单，就是内存不够用了（啤酒【对象】太多，杯子【内存】装不下了）

那啥是内存泄漏呢？

内存泄漏：Memory Leak

特意查了一下 Leak 的字典含义，解释1的直白翻译是【通常是由于错误或失误，从一个开口 进入或逃脱】

所以程序中的内存泄漏我的理解更多是：由于程序的编写错误暴漏出一些 开口，导致一些对象进入这写开口，最终导致相关问题，进一步说白了，程序有漏洞，不当的调用就会出问题

所以接下来我们主要来看看 Java 内存泄漏，以及问题的起因 hashCode 和内存泄漏到底有哪些关系

内存泄漏

咱也是一个有身份证的人，不能总讲大白话，相对官方的内存泄漏解释是这样滴：

内存泄漏说明的是这样一种情况：堆中存在一些不再使用的对象，但垃圾收集器无法将它们从内存中删除（垃圾收集器定期删除未引用的对象，但从不收集仍在引用的对象），因此对它们进行了不必要的维护

这句话略显抽象，一张图你就能明白

如果有用的、但垃圾收集器又不能删除的对象增多，就像下图这样，那么就会逐渐导致内存溢出(OOM)了

所以也可以总结为，OOM 的原因之一可能是内存泄漏导致的

内存泄漏会带来哪些问题

内存泄漏，会导致真正可用内存变少，在没达到 OOM 的这个过程中，就会出现奇奇怪怪的问题

1. 当应用程序长时间连续运行时，性能会严重下降，毕竟可用内存变小
2. 自发的和奇怪的应用程序崩溃
3. 应用程序偶尔会耗尽连接对象（这个经常听说吧）
4. 最终的结果是 OOM

所以也可以反过来推理，如果发生上述问题，有可能程序的某些地方发生了内存泄漏

那常见的哪些情形可能会引起内存泄漏呢？又有哪些解决办法呢？

会引起内存泄漏的常见情形与相应解决办法

静态成员变量的乱用

直接来看一个例子