道阻且长,行则将至

Scroll Down

如何优化多线程上下文切换

如果是单个线程,在 CPU 调用之后,那么它基本上是不会被调度出去的。如果可运行的线程数远大于 CPU 数量,那么操作系统最终会将某个正在运行的线程调度出来,从而使其它线程能够使用 CPU ,这就会导致上下文切换。还有,在多线程中如果使用了竞争锁,当线程由于等待竞争锁而被阻塞时,JVM 通常会将这个

Stream的一些内容

官方将 Stream 中的操作分为两大类:中间操作(Intermediate operations)和终结操作(Terminal operations)。中间操作只对操作进行了记录,即只会返回一个流,不会进行计算操作,而终结操作是实现了计算操作。中间操作又可以分为无状态(Stateless)与有状态

系统性能调优标准

在我们了解性能指标之前,我们先来了解下哪些计算机资源会成为系统的性能瓶颈。CPU:有的应用需要大量计算,他们会长时间、不间断地占用 CPU 资源,导致其他资源无法争夺到 CPU 而响应缓慢,从而带来系统性能问题。例如,代码递归导致的无限循环,正则表达式引起的回溯,JVM 频繁的 FULL GC,以及

LongAdder源码

前言并发场景下通常会使用 AtomicLong 原子类进行计数等操作,在 JDK1.8 中提供了 LongAdder 来实现类似功能。相对于 AtomicLong ,LongAdder 有着更高的性能,可以完全替代 AtomicLong 的计数操作。下面我们先对 AtomicLong 简单介绍,然后

CopyOnWriteArrayList源码分析

前言ArrayList 是一个非线程安全集合,需要使用方自行处理线程安全问题,或者使用 Collections.synchronizedList 包装。从 JDK 1.5 开始 JUC 中提供了使用写时复制机制实现的并发容器 CopyOnWriteArrayList。概述CopyOnWriteArr

线程数设置原则

在实际工作中,我们需要根据任务类型的不同选择对应的策略。CPU 密集型任务首先,我们来看 CPU 密集型任务,比如加密、解密、压缩、计算等一系列需要大量耗费 CPU 资源的任务。对于这样的任务最佳的线程数为 CPU 核心数的 1~2 倍,如果设置过多的线程数,实际上并不会起到很好的效果。此时假设我们

线程池拒绝策略

线程池拒绝策略时机第一种情况是当我们调用 shutdown 等方法关闭线程池后,即便此时可能线程池内部依然有没执行完的任务正在执行,但是由于线程池已经关闭,此时如果再向线程池内提交任务,就会遭到拒绝。第二种情况是线程池没有能力继续处理新提交的任务,也就是工作已经非常饱和的时候。线程池拒绝策略第一种拒