写点什么

死磕 Java 并发

0 人感兴趣 · 14 次引用

  • 最新
  • 推荐
https://static001.geekbang.org/infoq/a6/a624fd5a64d993647e9e946614c2dc20.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之深入分析 CAS

用户头像
chenssy11 月 29 日

CAS,Compare And Swap,即比较并交换。Doug lea大神在同步组件中大量使用CAS技术鬼斧神工地实现了Java多线程的并发操作。整个AQS同步组件、Atomic原子类操作等等都是以CAS实现的,甚至ConcurrentHashMap在1.8的版本中也调整为了CAS+Synchronized。可以说CAS

https://static001.geekbang.org/infoq/c4/c49bd8dc8c9599dd270c6aeea518641c.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之 Condition

用户头像
chenssy11 月 28 日

在没有Lock之前,我们使用synchronized来控制同步,配合Object的wait()、notify()系列方法可以实现等待/通知模式。在Java SE5后,Java提供了Lock接口,相对于Synchronized而言,Lock提供了条件Condition,对线程的等待、唤醒操作更加详细和灵活。下图是Condi

https://static001.geekbang.org/infoq/0b/0babf08907a8d0145459d4b2e9e62a02.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之读写锁:ReentrantReadWriteLock

用户头像
chenssy11 月 27 日

重入锁ReentrantLock是排他锁,排他锁在同一时刻仅有一个线程可以进行访问,但是在大多数场景下,大部分时间都是提供读服务,而写服务占有的时间较少。然而读服务不存在数据竞争问题,如果一个线程在读时禁止其他线程读势必会导致性能降低。所以就提供了读写

https://static001.geekbang.org/infoq/8c/8c1df291af2aa5495e001f18bf41fcdb.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之 AQS:阻塞和唤醒线程

用户头像
chenssy11 月 24 日

在线程获取同步状态时如果获取失败,则加入CLH同步队列,通过通过自旋的方式不断获取同步状态,但是在自旋的过程中则需要判断当前线程是否需要阻塞,其主要方法在acquireQueued():

https://static001.geekbang.org/infoq/36/36d4ebfa578060203698e278bf50910a.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之 AQS:同步状态的获取与释放

用户头像
chenssy11 月 23 日

在前面提到过,AQS是构建Java同步组件的基础,我们期待它能够成为实现大部分同步需求的基础。AQS的设计模式采用的模板方法模式,子类通过继承的方式,实现它的抽象方法来管理同步状态,对于子类而言它并没有太多的活要做,AQS提供了大量的模板方法来实现同步

https://static001.geekbang.org/infoq/08/0822c55783429679be1533f12c0ac6b3.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之 AQS:CLH 同步队列

用户头像
chenssy11 月 22 日

在上篇博客【死磕Java并发】-----J.U.C之AQS:AQS简介中提到了AQS内部维护着一个FIFO队列,该队列就是CLH同步队列。

https://static001.geekbang.org/infoq/e7/e77bcf095a0dfad0d787afeddcdb83c7.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----J.U.C 之 AQS:AQS 简介

用户头像
chenssy11 月 21 日

Java的内置锁一直都是备受争议的,在JDK 1.6之前,synchronized这个重量级锁其性能一直都是较为低下,虽然在1.6后,进行大量的锁优化策略(【死磕Java并发】-----深入分析synchronized的实现原理),但是与Lock相比synchronized还是存在一些缺陷的:虽然synch

https://static001.geekbang.org/infoq/6c/6cd519608ed7dc077f915055805b1684.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----Java 内存模型之总结

用户头像
chenssy11 月 19 日

经过四篇博客阐述,我相信各位对Java内存模型有了最基本认识了,下面LZ就做一个比较简单的总结。

【死磕 Java 并发】-----Java 内存模型之从 JMM 角度分析 DCL

用户头像
chenssy11 月 18 日

DCL,即Double Check Lock,中卫双重检查锁定。其实DCL很多人在单例模式中用过,LZ面试人的时候也要他们写过,但是有很多人都会写错。他们为什么会写错呢?其错误根源在哪里?有什么解决方案?下面就随LZ一起来分析

https://static001.geekbang.org/infoq/20/2035432bfdfc97a7da7ea4d2afac0a5e.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】-----Java 内存模型之重排序

用户头像
chenssy11 月 10 日

在执行程序时,为了提供性能,处理器和编译器常常会对指令进行重排序,但是不能随意重排序,不是你想怎么排序就怎么排序,它需要满足以下两个条件:

【死磕 Java 并发】-----Java 内存模型之 happens-before

用户头像
chenssy11 月 9 日

在上篇博客(【死磕Java并发】-----深入分析volatile的实现原理)LZ提到过由于存在线程本地内存和主内存的原因,再加上重排序,会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下,线程A修改了变量a何时对线程B可见?

https://static001.geekbang.org/infoq/d8/d882c3fd9f2edd0cf7d825a551be505d.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】—–深入分析 volatile 的实现原理

用户头像
chenssy11 月 6 日

通过前面一章我们了解了synchronized是一个重量级的锁,虽然JVM对它做了很多优化,而下面介绍的volatile则是轻量级的synchronized。如果一个变量使用volatile,则它比使用synchronized的成本更加低,因为它不会引起线程上下文的切换和调度。Java语言规范对vo

https://static001.geekbang.org/infoq/2e/2e08ee2d3b34b7916c82afcba5e14175.jpeg?x-oss-process=image/resize,w_416,h_234

【死磕 Java 并发】----- 深入分析 synchronized 的实现原理

用户头像
chenssy11 月 4 日

记得刚刚开始学习Java的时候,一遇到多线程情况就是synchronized,相对于当时的我们来说synchronized是这么的神奇而又强大,那个时候我们赋予它一个名字“同步”,也成为了我们解决多线程情况的百试不爽的良药。但是,随着我们学习的进行我们知道synchronize

死磕 Java 并发_死磕 Java 并发资料文章-InfoQ写作平台