前言 上一篇文章 不会用Java Future,我怀疑你泡茶没我快 全面分析了 Future,通过它我们可以获取线程的执行结果,它虽然解决了 Runnable 的 “三无” 短板,但是它自身还是有短板: 不能手动完成计算 假设你使用 Future 运行子线程调用远程 API 来获取某款产品的最新价格,服务器由于洪灾宕机了,此时如果你想手动结束计算,而是想返回上次缓存中的价格,这是 Future 做不到的 调用 get() 方法会阻塞程序 Future 不会通知你它的完成,它提供了一个get()方法,程序调用该方法会阻塞直到结果可用为止,没有办法利用回调函数附加到Future,并在Fut
前言 创建线程有几种方式?这个问题的答案应该是可以脱口而出的吧 * 继承 Thread 类 * 实现 Runnable 接口 但这两种方式创建的线程是属于”三无产品“: * 没有参数 * 没有返回值 * 没办法抛出异常 1 2 3 4 5 6 class MyThread implements Runnable{ @Override public void run() { log.info("my thread"); } } Runnable 接口是 JDK1.0 的核心产物 1 2 3 4 5 6 7 /** * @since
前言 并发编程的三大核心是分工,同步和互斥。在日常开发中,经常会碰到需要在主线程中开启多个子线程去并行的执行任务,并且主线程需要等待所有子线程执行完毕再进行汇总的场景,这就涉及到分工与同步的内容了 在讲 有序性可见性,Happens-before来搞定 时,提到过 join() 规则,使用 join() 就可以简单的实现上述场景: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 @Slf4j public class JoinExample { pub
前言 * 文章 Java AQS队列同步器以及ReentrantLock的应用 介绍了AQS独占式获取同步状态的实现,并以 ReentrantLock 为例说明其是如何自定义同步器实现互斥锁的 * 文章 Java AQS共享式获取同步状态及Semaphore的应用分析 介绍 AQS 共享式获取同步状态的实现,并说明了 Semaphore 是如何自定义同步器实现简单限流作用的 有了以上两篇文章的铺垫,来理解本文要介绍的既有独占式,又有共享式获取同步状态的 ReadWriteLock,就非常轻松了 ReadWriteLock ReadWriteLock 直译过来为【读写锁】。现实中,读
现陆续将Demo代码和技术文章整理在一起 Github实践精选 ,方便大家阅读查看,本文同样收录在此,觉得不错,还请Star🌟 看到本期内容这么少,是不是心动了呢? 前言 上一篇万字长文 Java AQS队列同步器以及ReentrantLock的应用 为我们读 JUC 源码以及其设计思想做了足够多的铺垫,接下来的内容我将重点说明差异化,如果有些童鞋不是能很好的理解文中的一些内容,强烈建议回看上一篇文章,搞懂基础内容,接下来的阅读真会轻松加愉快 AQS 中我们介绍了独占式获取同步状态的多种情形: * 独占式获取锁 * 可响应中断的独占式获取锁 * 有超时限制的独占式获
写在前面 进入源码阶段了,写了十几篇的 并发系列 知识铺垫终于要派上用场了。相信很多人已经忘了其中的一些理论知识,别担心,我会在源码环节带入相应的理论知识点帮助大家回忆,做到理论与实践相结合,另外这是超长图文,建议收藏,如果对你有用还请点赞让更多人看到 Java SDK 为什么要设计 Lock 曾几何时幻想过,如果 Java 并发控制只有 synchronized 多好,只有下面三种使用方式,简单方便 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class ThreeSync { private static fina
| 好看请赞,养成习惯 * 你有一个思想,我有一个思想,我们交换后,一个人就有两个思想 * If you can NOT explain it simply, you do NOT understand it well enough 现陆续将Demo代码和技术文章整理在一起 Github实践精选 ,方便大家阅读查看,本文同样收录在此,觉得不错,还请Star🌟 横看成岭侧成峰,远近高低各不同,并发编程理论系列基本已经结束,相信大家有了理论的铺垫,近看源码才能发现其设计之美,不会一头雾水 本来是要介绍 AQS 作为我们走进并发编程源码环节的
上一篇文章 面试问我,创建多少个线程合适?我该怎么说 从定性到定量的分析了如何创建正确个数的线程来最大化利用系统资源(其实就是几道小学数学题)。通常来讲,有了个这个知识点傍身,按需手动创建相应个数的线程就好 但是现实中,你也许听过或者被要求: 尽量避免手动创建线程,应使用线程池统一管理线程 为什么会有这样的要求?背后的道理又是怎样的呢?顺着这个经验理论来推断,那肯定是手动创建线程有缺点 手动创建线程有什么缺点? 1. 不受控风险 2. 频繁创建开销大 不受控风险 这个缺点,相信你也可以说出一二 系统资源有限,每个人针对不同业务都可以手动创建线程,并且创建标准不一样(比如线程没有
为什么要使用多线程? 防止并发编程出错最好的办法就是不写并发程序 既然多线程编程容易出错,为什么它还经久不衰呢? A:那还用说,肯定在某些方面有特长呗,比如你知道的【它很快,非常快】 我也很赞同这个答案,但说的不够具体 并发编程适用于什么场景? 如果问你选择多线程的原因就是一个【快】字,面试也就不会出那么多幺蛾子了。你有没有问过你自己 1. 并发编程在所有场景下都是快的吗? 2. 知道它很快,何为快?怎样度量? 想知道这两个问题的答案,我们需要一个从【定性】到【定量】的分析过程 使用多线程就是在正确的场景下通过设置正确个数的线程来最大化程序的运行速度(我感觉你还是啥也没
为什么要了解线程的生命周期? 之前写过 Spring Bean 生命周期三部曲: 1. Spring Bean生命周期之缘起 2. Spring Bean生命周期之缘尽 3. Spring Aware 到底是什么? 有朋友留言说:“了解了它们的生命周期后,使用 Spring Bean 好比看到它们的行动轨迹,现在使用就一点都不慌了”。我和他一样,了解事物的生命周期目的很简单,唯【不慌】也 Java 并发系列 已经写了很多,从来还没提起过那个它【Java线程生命周期】。有了前序理论图文的铺垫,在走进源码世界之前,谈论它的时机恰好到了。因为,编写并发程序的核心之一就是正确的摆弄线程



Copyright 2018-2019 Tanθ's Blog   |   辽ICP备19017651号-1   |     站点总字数: 221.2k 字   |   载入天数...载入时分秒...   |  站点地图   |  站长统计
  总访问量:  次  总访问人数:  人

博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议