LinkedHashMap数据结构分析，附带图片缓存思路

写安卓用到图片缓存。

download的代码用了一个LruCache（实际上也是个LinkedHashMap）和一个LinkedHashMap来存储bitmap。（当然还有用SD卡缓存啊）

其中LruCache<String, Bitmap>存强引用（固定空间大小，清除图片不减小LruCache大小），LinkedHashMap<String, SoftReference<String, Bitmap>>存弱引用

为什么要用两个LinkedHashMap呢(⊙o⊙)？

代码原作者的意图是，用SoftReference来指向从LruCache中清除的图片，so，在gc回收弱引用对象之前，这些对象可以直接调用（内存不够用时，执行gc线程）。

然而这篇博文的目的不是记录这个东西

关于LinkedHashMap的执行效率：

总的来说，LinkedHashMap把LinkList和HashTable的优点结合了。

LinkList链表的优点在于时间复杂度O(1)的增删节点操作，缺点是访问任意节点的时间复杂度是O(n)；

HashTable哈希表的优点在于访问任意节点的时间复杂度近似于O(1)（当然不能是我这种渣渣写的哈希算法）。

在LinkedHashMap中，（我猜）节点是这样的：

Struct Node{

    Object data;

    Node* linkListPrevious;

    Node* linkListNext;

    //Node* hashTablePrevious;    //看了源码发现没有这个

    Node* hashTableNext;

}

//(⊙o⊙)？LinkedHashMap不是Java的东东嘛？

此外，LinkedHashMap源码中的LinkList是个双向循环链表

为什么LinkedHashMap中的Node（Java中是Entry）没有hashTablePrevious这个引用呢？有这个引用删节点多块啊！

LinkedHashMap的父类HashMap中的Entry的数据成员有key / value / next / hash（哈希值），

HashMap的删节点操作是，声明2个指针（引用，Java源码中取的当前e以及上一个prev）prev->next = e->next

LinkedHashMap沿用了这个删除机制，这样的话，删除时就得遍历某个hash值后的小链表，不过遍历就遍历吧，反正桶高不会很大，节省了一个指针空间。。。

这样看来LinkedHashMap也不是很难啊（梗），为什么要记录呢？

=。=因为之前没想到

=。=确定我是在做IOS实习么