Fork/Join 框架是一种在 JDK 7 引入的线程池，用于并行执行把一个大任务拆成多个小任务并行执行，最终汇总每个小任务结果得到大任务结果的特殊任务。通过其命名也很容易看出框架主要分为 Fork 和 Join 两个阶段，第一阶段 Fork 是把一个大任务拆分为多个子任务并行的执行，第二阶段 Join 是合并这些子任务的所有执行结果，最后得到大任务的结果。
这里不难发现其执行主要流程：首先判断一个任务是否足够小，如果任务足够小，则直接计算，否则，就拆分成几个更小的小任务分别计算，这个过程可以反复的拆分成一系列小任务。Fork/Join 框架是一种基于 分治 的算法，通过拆分大任务成多个独立的小任务，然后并行执行这些小任务，最后合并小任务的结果得到大任务的最终结果，通过并行计算以提高效率。
你好，我是看山。
本文还是折腾 Java 中的队列，上次比较了 Vector、ArrayList、CopyOnWriteArrayList、SynchronizedList，当时感觉挺明白，后来想想又有些不理解的地方，所以今天在重新翻出来研究一下，我承认我钻了牛角尖了。
你好，我是看山。
书接上文，上次聊了聊 在多线程中使用 ArrayList 会发生什么，这次我们说说平时常用的列表：Vector、ArrayList、CopyOnWriteArrayList、SynchronizedList。
你好，我是看山。
前面写过一篇文章 《如果非要在多线程中使用 ArrayList 会发生什么？》，有读者反馈，Java 11 代码已经修复，还会出现 null 元素。
为了便于理解，当时只是通过代码执行顺序说明了异常原因。其实多线程中还会涉及 Java 内存模型，本文就从这方面说明一下。
你好，我是看山。
我们都知道，Java中的ArrayList是非线程安全的，这个知识点太熟了，甚至面试的时候都很少问了。
但是我们真的清楚原理吗？或者知道多线程情况下使用ArrayList会发生什么？
前段时间，我们就踩坑了，而且直接踩了两个坑，今天就来扒一扒。
本文来自公众号“Kahuna”，可搜索Alitaba119，欢迎关注，转载请注明出处，非常感谢
“ A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.”
这是CountDownLatch这个类要解决的问题：实现一个同步器，让一个或者多个线程一直等待，直到一组在其他线程中执行的操作完成。
阅读全文上午刚到公司，准备开始一天的摸鱼之旅时突然收到了一封监控中心的邮件。
心中暗道不好，因为监控系统从来不会告诉我应用完美无 bug，其实系统挺猥琐。
打开邮件一看，果然告知我有一个应用的线程池队列达到阈值触发了报警。
由于这个应用出问题非常影响用户体验；于是立马让运维保留现场 dump 线程和内存同时重启应用，还好重启之后恢复正常。于是开始着手排查问题。
熟悉 Java 并发编程的都知道，JMM(Java 内存模型) 中的 happen-before(简称 hb)规则，该规则定义了 Java 多线程操作的有序性和可见性，防止了编译器重排序对程序结果的影响。按照官方的说法：
当一个变量被多个线程读取并且至少被一个线程写入时，如果读操作和写操作没有 HB 关系，则会产生数据竞争问题。 要想保证操作 B 的线程看到操作 A 的结果（无论 A 和 B 是否在一个线程），那么在 A 和 B 之间必须满足 HB 原则，如果没有，将有可能导致重排序。 当缺少 HB 关系时，就可能出现重排序问题。
在 java.util.concurrent.locks.Lock 接口的Javadoc中有这样一段话：
All Lock implementations must enforce the same memory synchronization semantics as provided by the built-in monitor lock :
- A successful lock operation acts like a successful monitorEnter action
- A successful unlock operation acts like a successful monitorExit action
Unsuccessful locking and unlocking operations, and reentrant locking/unlocking operations, do not require any memory synchronization effects.
这段话的核心是j.u.c.locks.Lock接口的实现类具有和synchronized内置锁一样的内存同步语义。
不同于由JVM底层实现的内置锁，Lock接口的实现类是直接用Java代码实现的。如何保证了内存中数据的可见性？下面进行一下分析。
作者：佐井 原文地址
最近上线一个需求，完成需求的过程对代码进行了一次重构。应用发布后半个小时左右，发现一个机器报警，load过高。登陆机器看CPU使用情况，发现load已经正常，看下CPU使用情况，发现有一个核跑满，其他CPU使用率很低。大概一个小时后，其他机器陆续报警，发现同样的问题，紧急回滚应用。
应用运行在16G内存的虚机上，整个JVM11G内存，其中新生代3G，CMS gc，JDK7。
第一反应是JVM可能在进行full gc，因为只有一个线程跑满，其他线程被JVM暂停了。先去应用日志看下应用运行情况，果然日志已经没有任何输出。jstat -gcutil查看JVM内存使用情况，发现Old区使用已经100%。
(13 votes, average: 4.23 out of 5)
Loading...