liuwushuang233的博客

如果通过复用Bitmap来解码图片，如果被复用的Bitmap的内存比待分配内存的Bitmap大,那么getByteCount()表示新解码图片占用内存的大小（并非实际内存大小,实际大小是复用的那个Bitmap的大小），getAllocationByteCount()表示被复用Bitmap真实占用的内存大小(getByteCount永远小于等于getAllocationByteCount)这个值和透明度通道有关，默认值是true，如果设置为true，则返回的bitmap的颜色通道上会预先附加上透明度通道。

系统给VM分配了一定的内存大小，app可以申请使用的内存大小不能超过此硬件逻辑限制，就算物理内存富余，如果应用超过VM最大内存，就会出现内存溢出crash。产生泄漏之后不会立马导致应用崩溃，1个地方存在泄漏，程序跑久了之后，内存泄漏会一直积攒着，达到OOM级别，会导致应用低内存，会导致发热，耗电更严重的导致内存溢出。在AS中的Profiler中使用查看波动图，内存抖动会频繁GC，如自定义view中的ondraw（）中频繁创建销毁画笔路径等，最后会导致内存千疮百孔。即OOM,OOM时会导致程序异常。

虚引用是最弱的一种引用关系，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，它随时可能会被回收，在 JDK1.2 之后，用 PhantomReference 类来表示，通过查看这个类的源码，发现它只有一个构造函数和一个 get() 方法，而且它的 get() 方法仅仅是返回一个null，也就是说将永远无法通过虚引用来获取对象，虚引用必须要和 ReferenceQueue 引用队列一起使用。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null，这样一来，JVM就可以适时的回收对象了。

k为object类型，根据k找到int类型的hashcode，装箱过程，table []大小未知，根据hashcode % table的length求模运算，得到范围0-length-1，求模运算等价于位运算，源码中使用的是位运算，更快，往JVM转为字节码时速度更快，这时得到下标index即源码中的i，通过下标i找到要操作的位置，完成k的任务。扩容耗性能，避免扩容，创建时应该评估hash表的大小，（大小/0.75+1），如何保证大小为2的次幂，这就和put时有关。避免冲突，长度更大，冲突的可能性更低。