前言开发中不免会遇到需要所有子线程执行完毕通知主线程处理某些逻辑的场景。 或者是线程 A 在执行到某个条件通知线程 B 执行某个操作。 可以通过以下几种方式实现： 等待通知机制 等待通知模式是 Java 中比较经典的线程通信方式。 两个线程通过对同一对象调用等待 wait() 和通知 notify() 方法来进行通讯。 如两个线程交替打印奇偶数：

前言不管是在面试还是实际开发中 volatile 都是一个应该掌握的技能。 首先来看看为什么会出现这个关键字。 内存可见性由于 Java 内存模型(JMM)规定，所有的变量都存放在主内存中，而每个线程都有着自己的工作内存(高速缓存)。 线程在工作时，需要将主内存中的数据拷贝到工作内存中。这样对数据的任何操作都是基于工作内存(效率提高)，并且不能直接操作主内存以及其他线程工作内存中的数据，之后再将

众所周知 HashMap 是一个无序的 Map，因为每次根据 key 的 hashcode 映射到 Entry 数组上，所以遍历出来的顺序并不是写入的顺序。 因此 JDK 推出一个基于 HashMap 但具有顺序的 LinkedHashMap 来解决有排序需求的场景。 它的底层是继承于 HashMap 实现的，由一个双向链表所构成。 LinkedHashMap 的排序方式有两种： 根据写入顺序

使用 synchronize 来做同步处理时，锁的获取和释放都是隐式的，实现的原理是通过编译后加上不同的机器指令来实现。 而 ReentrantLock 就是一个普通的类，它是基于 AQS(AbstractQueuedSynchronizer)来实现的。 是一个重入锁：一个线程获得了锁之后仍然可以反复的加锁，不会出现自己阻塞自己的情况。 AQS 是 Java 并发包里实现锁、同步的一个重要的基

创建对象当 JVM 收到一个 new 指令时，会检查指令中的参数在常量池是否有这个符号的引用，还会检查该类是否已经被加载过了，如果没有的话则要进行一次类加载。 接着就是分配内存了，通常有两种方式： 指针碰撞 空闲列表 使用指针碰撞的前提是堆内存是完全工整的，用过的内存和没用的内存各在一边每次分配的时候只需要将指针向空闲内存一方移动一段和内存大小相等区域即可。 当堆中已经使用的内存和未使用的内

众所周知 synchronized 关键字是解决并发问题常用解决方案，有以下三种使用方式: 同步普通方法，锁的是当前对象。 同步静态方法，锁的是当前 Class 对象。 同步块，锁的是 () 中的对象。 实现原理：JVM 是通过进入、退出对象监视器( Monitor )来实现对方法、同步块的同步的。 具体实现是在编译之后在同步方法调用前加入一个 monitor.enter 指令，在退出方法和

当我们在做数据库分库分表或者是分布式缓存时，不可避免的都会遇到一个问题: 如何将数据均匀的分散到各个节点中，并且尽量的在加减节点时能使受影响的数据最少。 Hash 取模随机放置就不说了，会带来很多问题。通常最容易想到的方案就是 hash 取模了。 可以将传入的 Key 按照 index = hash(key) % N 这样来计算出需要存放的节点。其中 hash 函数是一个将字符串转换为正整数的哈

前言看过之前SBC系列的小伙伴应该都可以搭建一个高可用、分布式的微服务了。 目前的结构图应该如下所示: 各个微服务之间都不存在单点，并且都注册于 Eureka ，基于此进行服务的注册于发现，再通过 Ribbon 进行服务调用，并具有客户端负载功能。 一切看起来都比较美好，但这里却忘了一个重要的细节： 当我们需要对外提供服务时怎么处理？ 这当然也能实现，无非就是将我们具体的微服务地址加端口暴露

原文链接1 在 GitHub.com 编辑代码我将从我认为大家都知道的一件事情开始(尽管我是直到一周前才知道)。 当你在 GitHub 查看文件时(任何文本文件，任何仓库中)，右上角会有一个小铅笔图标，点击它就可以编辑文件了。完成之后点击 Propose file change 按钮 GitHub 将会自动帮你 fork 该项目并且创建一个 pull request 。 很厉害吧！他自动帮你 f

前言写这篇文章的起因是由于之前的一篇关于Kafka异常消费，当时为了解决问题不得不使用临时的方案。 总结起来归根结底还是对Kafka不熟悉导致的，加上平时工作的需要，之后就花些时间看了Kafka相关的资料。 何时使用MQ谈到Kafka就不得不提到MQ，是属于消息队列的一种。作为一种基础中间件在互联网项目中有着大量的使用。 一种技术的产生自然是为了解决某种需求，通常来说是以下场景： 需要跨进程