Redis的字典与ConcurrentHashMap的扩容策略比较
来源:互联网 发布:步步高i270软件下载 编辑:程序博客网 时间:2024/06/10 10:30
本文介绍Redis的字典(是种Map)与ConcurrentHashMap的扩容策略,并比较它们的优缺点。
(不讨论它们的实现细节)
首先Redis的字典采用的是一种‘’单线程渐进式rehash‘’,这里的单线程是指只有一个线程在扩容,
而在扩容的同时其他的线程可以并发的进行读写。
Redis系统后台会定时给予扩容的那个线程足够的运行时间,这样不会导致它饿死。
大致过程是这样的:
ht[0],是存放数据的table,作为非扩容时容器。
ht[1],只有正在进行扩容时才会使用,它也是存放数据的table,长度为ht[0]的两倍。
扩容时,单线程A负责把数据从ht[0] copy到ht[1] 中。如果这时有其他线程
进行读操作:会先去ht[0]中找,找不到再去ht[1]中找。
进行写操作:直接写在ht[1]中。
进行删除操作:与读类似。
当然这过程中会设计到一系列的锁来保证同步性,不过这并不是本文的重点。
而ConcurrentHashMap采用的扩容策略为: "多线程协同式rehash"。
这里的多线程指的是,有多个线程并发的把数据从旧的容器搬运到新的容器中。
扩容时大致过程如下:
线程A在扩容把数据从oldTable搬到到newTable,这时其他线程
进行get操作:这个线程知道数据存放在oldTable或是newTable中,直接取即可。
进行写操作:如果要写的桶位,已经被线程A搬运到了newTable。
那么这个线程知道正在扩容,它也一起帮着扩容,扩容完成后才进行put操作。
进行删除操作:与写一致。
两者对比:
1.扩容所花费的时间对比:
一个单线程渐进扩容,一个多线程协同扩容。在平均的情况下,是ConcurrentHashMap快。这也意味着,扩容时所需要
花费的空间能够更快的进行释放。
2.读操作,两者的性能相差不多。
3.写操作,Redis的字典返回更快些,因为它不像ConcurrentHashMap那样去帮着扩容(当要写的桶位已经搬到了newTable时),等扩容完才能进行操作。
4.删除操作,与写一样。
所以是选择单线程渐进式扩容还是选择多线程协同式扩容,这个就具体问题具体分析了。
1.如果内存资源吃紧,希望能够进行快速的扩容方便释放扩容时需要的辅助空间,且那么选择后者。
2.如果对于写和删除操作要求迅速,那么可以选择前者。
个人觉得ConcurrentHashMap的扩容策略更让人惊艳,效果也不错。
- Redis的字典与ConcurrentHashMap的扩容策略比较
- java基础--hashTable与concurrentHashMap的比较
- ConcurrentHashMap的扩容机制(jdk1.8)
- HashMap&ConcurrentHashMap的比较
- Java和Android中ArrayList与Vector的扩容比较
- ConcurrentHashMap的使用场景以及与HashTable的比较
- 针对单一数据表进行扩容时优化速度的策略比较
- concurrenthashmap和 synchronized的比较
- HashMap与ConcurrentHashMap的比较(包含底层实现原理)
- HashMap的扩容机制, ConcurrentHashMap和Hashtable主要区别
- Redis与Memcached的比较
- Redis与Memcached的比较
- Redis与Memcached的比较
- Redis与Memcached的比较
- redis与memcache的比较
- Redis与Memcached的比较
- Redis与Memcached的比较
- Redis与Memcached的比较
- Ubuntu 修改用户名
- MySQL查询:查询一个表中类别字段中Max()最大值对应的记录
- Java学习--day6
- Vue简介
- 基于AngularJs 省市区联动实践
- Redis的字典与ConcurrentHashMap的扩容策略比较
- io流基础认知
- C#与JAVA的DES加密结果一致的参数设置
- Nginx mogilefs module (v 1.0.4)文档
- Python 对dict 的 keys() 排序
- SQLite数据库的一些应用(应用单例模式)
- 深入浅出数据仓库中SQL性能优化之Hive篇
- 【Timer】定时器使用示例
- WiFi信号扩展的最佳方案