Java多线程八股(三)一>多线程环境使用哈希表和ArrayList

目录:

一.多线程环境使用ArrayList:

二.多线程使用哈希表:

一.多线程环境使用ArrayList:

首先我们知道,Vector, Stack, HashTable, 是线程安全的(但是不建议用), 其他的集合类不是线程安全的 ,下面是 ArrayList的使用场景
1.自行对代码加锁 (推荐使用)


2. 套个壳使用Collections.synchronizedList(new ArrayList)

就类似于上面的HashTable这些,但是不推荐使用因为使用加锁是有代价的(性能开销等等)
synchronizedList 是标准库提供的一个基于 synchronized 进行线程同步的 List. synchronizedList的关键操作方法上都带有 synchronized


3.使用 CopyOnWriteArrayList容器:

这个容器不是加锁设计的,而是用编程常见的一种思想方法->写时拷贝

以下是 写时拷贝的讲解:
注意:CopyOnWriteArrayList容器也不是所有场景都适合,当数组非常大和涉及多个线程修改时就会可能出错



二.多线程使用哈希表:
HashMap 本身不是线程安全的
在多线程环境下使用哈希表可以使用: Hashtable ConcurrentHashMap


1.Hashtable:
只是简单的把关键方法加上了 synchronized 关键字,(相当给this加锁,就是给整个哈希表加锁)
这样如果修改两个元素 不在同一个链表上,就是修改不同元素 , 不会发生线程安全问题
但是如果在同一个链表上就可能会发生线程安全问题 (比如把两个元素插入到第一个元素后面)



2.ConcurrentHashMap:
(1). 读操作没有加锁(但是使用了 volatile 保证从内存读取结果)


(2). 只对写操作进行加锁. 加锁的方式仍然是是⽤ synchronized, 但是不是锁整个对象, 而是"锁桶" (用每个链表的头结点作为锁对象), 大大降低了锁冲突的概率.


(3).充分利用CAS(原子类)特性. 比如 size 属性通过 CAS 来更新. 避免出现重量级锁的情况也避免了线程安全问题. (通过原子类修饰size)


(4).优化了扩容方式: 化整为零
化整为零解释:
扩容需要把旧的哈希表元素全部搬运一次性搬运到新的哈希表,这个时候如果元素太多搬运完,势必进行更长时间的加锁解锁,会很耗时间,这个时候就可以采用"化整为零"的方式,不是一次搬运完,而是多次进行搬运(一次搬运百分之几),后续再进行基本操作,这样加锁解锁耗时就很短,分多次部分触发完成全部任务

相关推荐
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 14 章 MCP 服务端(上):注解式实现与工具来源
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 15 章 MCP 服务端(下):三种协议形态、Streamable 传输与状态管理
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 16 章 向量存储(上):`VectorStore` 接口体系、`BatchingStrategy`
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 12 章 工具循环的流式形态、Usage 累加与扩展体系
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 23 章 模型供应商实现:从 `OpenAiSetup` 到 Bedrock
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 06 章 内置 Advisor 全景:13 个实现逐个剖到源码级
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 03 章 消息体系与 Prompt:不可变模型、`ChatOptions` 与模板渲染
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 24 章 生产实践与 2.x 迁移:陷阱清单、AOT 与调优
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 10 章 工具调用(中):执行链路、结果转换与工具限制
java·人工智能·开源
鶴哥只手遮天3 小时前
Spring AI 2.0.1 深度解析-第 13 章 MCP 客户端:传输、工具聚合与命名冲突
java·人工智能·开源