One Trick Per Day

简介: 初始化Map应避免容量设置不当,推荐使用Guava的`newHashMapWithExpectedSize`或手动计算容量。禁止使用`Executors`创建线程池,易因无界队列或过多线程引发OOM,应通过`ThreadPoolExecutor`显式定义参数。`Arrays.asList`返回不可变列表,不支持增删操作,且与原数组共享数据。遍历Map时优先使用`entrySet`或JDK8的`forEach`,提升性能。`SimpleDateFormat`非线程安全,建议用`ThreadLocal`隔离或使用Java 8新时间API。

1.初始化Map大小并非用多少指定多少
● 初始化Map并非用多少初始化Size是多少,建议使用Guava,避免扩容引起的动荡()
说明
● 如:Map map = new HashMap<>(1); 在具体使用时,并非size=1,而是最近的2的幂等,如1实际是2,3实际是4,9实际是16
使用方法
● 依赖gvaua:Map map = Maps.newHashMapWithExpectedSize(7);


com.google.guava
guava
17.0

● 手动声明:Map map = new HashMap<>(实际存储个数 / 0.75 + 1);
2.线程池初始化严禁使用Executors
使用线程池时候,我们可能会使用下面四个场景,这在alibaba代码规范中都是明令禁止的
// 创建一个单线程化的Executor[因为数量固定,可能会堆积大量请求,导致OOM]
private static ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();

// 创建一个固定数目线程的线程池[因为数量固定,可能会堆积大量请求,导致OOM]
private static ExecutorService fixedThreadPool = Executors.newFixedThreadPool(10);

// 创建一个可执行命令的单线程Executor[可能会创建大量的线程,导致OOM]
private static ExecutorService singleThreadScheduledExecutor = Executors.newSingleThreadScheduledExecutor();

// 创建一个可缓存的线程池(60S存活时间)[可能会创建大量的线程,导致OOM]
private static ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
我们先来一个简单的例子,模拟一下使用 Executors 导致 OOM 的情况。
public class ExecutorsDemo {
private static ExecutorService executor = Executors.newFixedThreadPool(15);
public static void main(String[] args) {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
executor.execute(new SubThread());
}
}
}
class SubThread implements Runnable {
@Override
public void run() {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
//do nothing
}
}
}
通过指定 JVM 参数:-Xmx8m -Xms8m 运行以上代码,会抛出 OOM:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
以上代码指出,ExecutorsDemo.java 的第 16 行,就是代码中的 executor.execute(new SubThread());。
通过上面的例子,我们知道了 Executors 创建的线程池存在 OOM 的风险,那么到底是什么原因导致的呢?我们需要深入 Executors 的源码来分析一下。其实,在上面的报错信息中,我们是可以看出蛛丝马迹的,在以上的代码中其实已经说了,真正的导致 OOM 的其实是 LinkedBlockingQueue.offer 方法。
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
如果读者翻看代码的话,也可以发现,其实底层确实是通过 LinkedBlockingQueue 实现的:
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue());
}
如果读者对 Java 中的阻塞队列有所了解的话,看到这里或许就能够明白原因了。Java 中 的 BlockingQueue 主 要 有 两 种 实 现, 分 别 是 ArrayBlockingQueue 和 LinkedBlockingQueue。ArrayBlockingQueue 是一个用数组实现的有界阻塞队列,必须设置容量。LinkedBlockingQueue 是一个用链表实现的有界阻塞队列,容量可以选择进行设置,不设置的话,将是一个无边界的阻塞队列,最大长度为 Integer.MAX_VALUE。这里的问题就出在:不设置的话,将是一个无边界的阻塞队列,最大长度为Integer.MAX_VALUE。也就是说,如果我们不设置 LinkedBlockingQueue 的容量的话,其默认容量将会是 Integer.MAX_VALUE。 而 newFixedThreadPool 中创建 LinkedBlockingQueue 时,并未指定容量。此时,LinkedBlockingQueue 就是一个无边界队列,对于一个无边界队列来说,是可以不断的向队列中加入任务的,这种情况下就有可能因为任务过多而导致内存溢出问题。上面提到的问题主要体现在 newFixedThreadPool 和 newSingleThreadExecutor 两个工厂方法上,并不是说newCachedThreadPool 和 newScheduledThreadPool 这两个方法就安全了,这两种方式创建的最大线程数可能是Integer.MAX_VALUE,而创建这么多线程,必然就有可能导致 OOM

正确使用:
private static ExecutorService executor = new ThreadPoolExecutor(10, 10, 60L, TimeUnit.SECONDS,
new ArrayBlockingQueue(10));
这种情况下,一旦提交的线程数超过当前可用线程数时,就会抛出java.util.concurrent.RejectedExecutionException,这是因为当前线程池使用的队列是有边界队列,队列已经满了便无法继续处理新的请求。但是异常(Exception)总比发生错误(Error)要好。
但是部分alibaba作者更推荐使用guava创建对应的线程池,示例如下:
public class ExecutorsDemo {
private static ThreadFactory namedThreadFactory = new
ThreadFactoryBuilder()
.setNameFormat("demo-pool-%d").build();
private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue(1024), namedThreadFactory, new
ThreadPoolExecutor.
AbortPolicy());
public static void main(String[] args) {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
pool.execute(new SubThread());
}
}
}
通过上述方式创建线程时,不仅可以避免 OOM 的问题,还可以自定义线程名称,更加方便的出错的时候溯源。
3.Arrays.asList之后不要调用修改操作
String[] str = new String[] { "you", "wu" };
List list = Arrays.asList(str);
因为asList返回的实际是一个Arrays内部类,并没有实现集合的修改方法(add/remove/clear)// 当操作修改方法时,会报UnsupportedOperationException。
第一种情况:list.add("yangguanbao"); 运行时异常。
第二种情况:str[0] = "gujin"; 那么 list.get(0)也会随之修改。[涉及栈堆指针操作,修改数组的数据,导致同样引用该数据的list值被改变]

4.使用 entrySet 遍历 Map 类集合 KV
说明:keySet 其实是遍历了 2 次,一次是转为 Iterator 对象,另一次是从 hashMap 中取出key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中,效率更高。
如果是 JDK8,使用 Map.foreach 方法。
正例:values()返回的是 V 值集合,是一个 list 集合对象;keySet()返回的是 K 值集合,是一个 Set 集合对象;entrySet()返回的是 K-V 值组合集合。
5.SimpleDateFormat不要定义为static
SimpleDateFormat 是线程不安全的类,一般不要定义为 static 变量,如果定义为static,必须加锁,或者使用 DateUtils 工具类。
正例:注意线程安全,使用 DateUtils。亦推荐如下处理:
private static final ThreadLocal df = new ThreadLocal() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
说明:如果是 JDK8 的应用,可以使用 Instant 代替 Date,LocalDateTime 代替 Calendar,DateTimeFormatter 代替 SimpleDateFormat,官方给出的解释:simple beautiful strong immutable thread-safe。
6.并发修改同一记录时需要加锁
要么在应用层加锁,要么在缓存加锁,要么在数据库层使用乐观锁,使用 version 作为更新依据。
说明:如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于 3 次

相关文章
|
9月前
|
存储 编解码 对象存储
在线教育平台云架构
在线教育平台云架构方案,聚焦万人课堂的高并发、低延迟需求,涵盖视频处理、实时互动、数据存储、安全合规等核心环节。通过CDN加速、弹性扩容、OSS存储、WebRTC互动与全链路安全防护,构建稳定、高效、可扩展的技术体系,支撑“教-学-考”全流程数字化教学,保障大规模在线学习体验流畅与内容安全。(238字)
541 1
|
9月前
|
存储 缓存 监控
存储成本与性能平衡
本文系统解析存储成本与性能平衡之道,涵盖选型、生命周期、压缩去重、缓存策略等十大核心维度,结合实战案例与决策树,助力企业构建低成本、高性能、高可靠的存储架构。
708 1
|
9月前
|
存储 人工智能 安全
医疗影像云存储方案
医疗影像云存储方案通过云原生技术,构建安全合规、高效智能的影像管理新范式。面对大文件、高并发、长周期保存等挑战,方案融合分层架构、分片传输、全链路加密与AI协同,实现弹性扩容、低延迟访问与成本优化,并已在三甲医院成功落地,助力精准医疗迈向高质量发展。(238字)
811 1
|
9月前
|
边缘计算 运维 监控
边缘计算场景实践
《边缘计算场景实践指南》系统阐述了边缘计算在5G、物联网与AI背景下的应用路径。涵盖云边端协同架构、ENS核心产品、CDN、视频分析与物联网等典型场景,详解部署流程、网络优化、安全防护与监控体系,并结合智慧工厂案例与成本分析,展望5G+边缘计算融合趋势,为企业落地边缘计算提供全面参考。(238字)
587 0
|
9月前
|
存储 弹性计算 监控
云账单分析与优化工具使用
本指南系统介绍云账单分析与优化工具的使用方法,涵盖账单解析、成本分摊、预算管理、资源优化等核心模块,助力企业实现云成本可视化、精细化管控,通过标签体系、智能建议与多账号协同,推动从“被动付费”到“主动治理”的转型,最大化释放云上成本优化潜力。(238字)
450 0
|
9月前
|
算法 量子技术 数据库
量子计算云服务初探
本文深入浅出地介绍量子计算云服务,涵盖量子比特、量子门基础,主流平台如阿里云“太章2.0”,核心算法Shor与Grover,编程框架及经典模拟技术,探讨其在化学计算与优化问题中的应用前景,并提供入门学习路径与实践案例,助力开发者迈向量子计算时代。(238字)
436 0
|
9月前
|
监控 JavaScript Java
Serverless冷启动优化
Serverless冷启动是影响性能的关键瓶颈,尤其在实时交互场景中。本文从冷启动原理出发,系统解析语言选型、镜像优化、预热策略、实例复用、内存配置等十大维度,结合API服务实战案例与成本控制技巧,提供可落地的优化方案。通过精简依赖、合理预热、动态调优,企业可在性能提升与成本间实现平衡,充分发挥Serverless降本增效优势。(238字)
727 0
|
9月前
|
缓存 安全 Java
容器镜像构建优化
本文系统讲解容器镜像构建优化十大核心方法,涵盖分层管理、多阶段构建、基础镜像选型、缓存利用、安全扫描等关键技术,结合实战案例与CI/CD自动化实践,助力企业打造轻量、安全、高效的容器镜像体系,全面提升部署效率与安全性。(238字)
488 0
|
9月前
|
边缘计算 监控 网络协议
网络延迟优化方案
本文系统阐述网络延迟优化全方案,涵盖架构设计、协议调优、全球加速等十大维度,结合实战案例与最佳实践,助力构建低延迟、高稳定网络体系。
1415 0
|
9月前
|
存储 运维 监控
存储分层降低成本实践
《存储分层降低成本实践指南》系统阐述企业如何通过数据分层管理优化存储成本。结合数据访问频率、业务需求与成本模型,指导企业构建标准、低频、归档及冷归档多级存储体系,借助生命周期规则、智能迁移与监控工具,实现热、温、冷数据自动流转,在保障性能的同时显著降低总体存储支出,助力数字化转型降本增效。(238字)
572 0