Java 搬运工 & 终身学习者。

什么是消息队列（MQ）

消息是在不同应用间传递的数据。这里的消息可以非常简单，比如只包含字符串，也可以非常复杂，包含多个嵌套的对象。消息队列（Message Queue）简单来说就是一种应用程序间的通讯方式，消息发送后立即返回，然后由消息系统保证消息的可靠性传输，消息生产者只需要把消息发到 MQ 中就可以了，不需要关心消息的消费，同样，消息消费者只管从 MQ 中拉取消息而不管是谁生产的消息，通过这样的一个“互相不知道对象存在”模式，将消息的生产者和消息的消费者解耦了。

什么场景下考虑使用消息队列

从上面可以知道，消息队列是一种应用间的异步协作机制，那么我们什么时候需要用到 MQ 呢？以常见的订单系统为例，当用户点击「下单」后的业务逻辑可能包括：扣减库存、生成相应订单数据、发短信通知等。在项目和业务发展初期上面这些逻辑可能放在一起执行，随着业务的发展订单量的增加，需要提升系统服务的性能，此时就可以将一些不需要立即生效的操作拆分出来异步执行，比如发送短信通知等。这种场景下就可以使用 MQ ，在下单主流程（比如扣减库存、生成订单数据等）完成之后发送一条消息到 MQ 让主流程快速走完，然后由另外一个线程拉取 MQ 的消息，执行相应的业务逻辑。这里的例子主要是用消息队列来解耦。

前言

在 Java 中通过 锁 来控制多个线程对共享资源的访问，使用 Java 编程语言开发的朋友都知道，可以通过 synchronized 关键字来实现锁的功能，它可以隐式的获取锁，也就是说我们使用该关键字并不需要去关心锁的获取和释放过程，但是在提供方便的同时也意味着其灵活性的下降。例如，有这样的一个场景，先获取锁 A，然后再获取锁 B，当锁 B 获取到之后，释放锁 A 同时获取锁 C，当获取锁 C 后，再释放锁 B 同时获取锁 D，依次类推，像这种比较复杂的场景，使用 synchronized 关键字就比较难实现了。
在 Java SE 5 之后，新增加了 Lock 接口和一系列的实现类来提供和 synchronized 关键字一样的功能，它需要我们显示的进行锁的获取和释放，除此之外还提供了可响应中断的锁获取操作以及超时获取锁等同步特性。JDK 中提供的 Lock 接口实现类大部分都是聚合一个同步器 AQS 的子类来实现多线程的访问控制的，下面我们看看这个构建锁和其它同步组件的基础框架——队列同步器 AQS（AbstractQueuedSynchronizer）。

前言

在计算机编程中，单元测试是一种软件测试方法，通过该方法可以测试源代码的各个单元功能是否适合使用。为代码编写单元测试有很多好处，包括可以及早的发现代码错误，促进更改，简化集成，方便代码重构以及许多其它功能。使用 Java 语言的朋友应该用过或者听过 Junit 就是用来做单元测试的，那么为什么我们还需要 Mockito 测试框架呢？想象一下这样的一个常见的场景，当前要测试的类依赖于其它一些类对象时，如果用 Junit 来进行单元测试的话，我们就必须手动创建出这些依赖的对象，这其实是个比较麻烦的工作，此时就可以使用 Mockito 测试框架来模拟那些依赖的类，这些被模拟的对象在测试中充当真实对象的虚拟对象或克隆对象，而且 Mockito 同时也提供了方便的测试行为验证。这样就可以让我们更多地去关注当前测试类的逻辑，而不是它所依赖的对象。

前言

对于使用 Java 语言开发的朋友可能会遇到这种情况，有时想学习和探索 Java 的最新版本提供的一些新特性，比如 Java 11，但你无法将其安装在自己的计算机上，因为你的团队正在使用比这个旧的版本（我们目前用的 Java 8)，你并不想影响目前的项目。或者你目前是在维护和开发多个项目，而这些不同的项目使用的 JDK 版本不一样，比如那些维护的老项目使用的是 JDK 8，而新项目你打算使用比较新的版本 JDK 11，以上这些情况都需要在计算机上安装多个 JDK，并且应该能够在多个版本之间方便快速的切换。今天要介绍的主角 SDKMAN 可以很好的解决上面这种问题，它提供了在同一台计算机上对多个版本的开发工具包管理。需要注意的是：这个工具只适用于类 Unix 的系统（比如：Mac OSX、Linux、Cygwin、Solaris、FreeBSD 等）。

前言

在网上看到过很多讲有关同步与异步、阻塞与非阻塞的文章，但是很多都是抛出一堆相关定义，看了之后还是云里雾里的，对这几个概念还是不能很好的去区分它们。本文通过通俗易懂的语言和相关例子让你深入理解其本质。

同步与异步

首先我们要明确的是，同步和异步都是针对两个或者两个以上的事物来说的。比如当我们在网上购物看中一件物品，然后去浏览该商品详情的时候，首先页面会先发送一个请求，后台服务器查询对应商品的相关数据，然后前端详情页面才根据返回数据展示该商品的详细信息。而此时你的网速比较差，一个详情页面等了将近一分钟才全部展示完成，这时候你问这个请求是同步还是异步？答案显然是同步请求，它给我们最直观的表现形式就是页面一直显示在加载中，商品的详情页面渲染必须要等待后台服务器返回商品详情数据后才能进行。也就是说下一个操作必须要等待上一个操作完成才能进行，它依赖于上一个操作的返回结果。

前言

在日常工作中，经常要判断一个元素是否在一个集合中。假设你要向浏览器添加一项功能，该功能可以通知用户输入的网址是否是恶意网址，此时你手上有大约 1000 万个恶意 URL 的数据集，你该如何实现该功能。按我之前的思维，要判断一个元素在不在当前的数据集中，首先想到的就是使用 hash table，通过哈希函数运行所有的恶意网址以获取其哈希值，然后创建出一个哈希表（数组）。这个方案有个明显的缺点，就是需要存储原始元素本身，内存占用大，而我们其实主要是关注 当前输入的网址在不在我们的恶意 URL 数据集中，也就是之前的恶意 URL 数据集的具体值是什么并不重要，通过吴军老师的《数学之美》了解到，对于这种场景大数据领域有个用于在海量数据情况下判断某个元素是否已经存在的算法很适合，关键的一点是该算法并不存储元素本身，这个算法就是 — 布隆过滤器(Bloom filter)。

原理

布隆过滤器是由巴顿.布隆于一九七零年提出的，在 维基百科 中的描述如下：

A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set.

前言

Java 里字符串表示字符的不可变序列，创建后就不能更改。在我们日常的工作中，字符串的使用非常频繁，熟练的对其操作可以极大的提升我们的工作效率，今天要介绍的主角是 Google 开源的一个核心 Java 库 Guava，它提供了集合类型、不可变的集合、并发、I / O、缓存、字符串等许多实用功能。在本文中，我们将学习使用 Guava 中的 Strings 和 Splitter 字符串操作工具类。

如何使用

Google Guava 会同步到 Maven Central 中，所以，如果你是 Maven 项目的话只需要在 pom.xml 文件中引入如下依赖即可：

1
2
3
4
5

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>28.2-jre</version>
</dependency>

对于 Gradle 项目在 build.gradle 中引入如下依赖即可：

1

compile group: 'com.google.guava', name: 'guava', version: '28.2-jre'

前言

在我们的意识里，同步执行的程序都比较符合人们的思维方式，而异步的东西通常都不好处理。在异步计算的情况下，以回调表示的动作往往会分散在代码中，也可能相互嵌套在内部，如果需要处理其中一个步骤中可能发生的错误时，情况变得更加糟糕。Java 8 引入了很多的新特性，其中就包含了 CompletableFuture 类的引入，这让我们编写清晰可读的异步代码变得更加容易，该类功能非常强大，包含了超过 50 多个方法。。。

什么是 CompletableFuture

CompletableFuture 类的设计灵感来自于 Google Guava 的 ListenableFuture 类，它实现了 Future 和 CompletionStage 接口并且新增了许多方法，它支持 lambda，通过回调利用非阻塞方法，提升了异步编程模型。它允许我们通过在与主应用程序线程不同的线程上（也就是异步）运行任务，并向主线程通知任务的进度、完成或失败，来编写非阻塞代码。

前言

在日常生活中，当我们买的水果放久了之后会发出一种难闻的气味（“坏味道”），这个时候我们就应该把它扔掉。同样，代码也有“坏味道”，当然确定什么是和不是代码“坏味道”是主观的，它会随语言、开发人员和开发方法的不同而不同。在工作当中，很多时候都是在维护之前的项目和在此基础上增加一些新功能，为了能让项目代码易于理解和维护，要时刻注意代码中的“坏味道”，当发现代码如果有坏味道了，要及时去重构它使其变成优秀的整洁的代码。本文列举代码中一些常见的“坏味道”和相应的重构方案。

过长方法 (Long Method)

这种“坏味道”表现为方法代码行数过长，方法行数越长，就越难以理解和维护它。一个比较有用的方案就是当你觉得需要对方法中的内容加注释的时候，你应该将这个代码段作为一个新方法提取出来，哪怕有时候仅仅是一行代码也可以这么做，而且方法的命名要尽量做到见名知意，如果局部变量和参数干扰到方法的提取，则可以使用引入参数对象来进行提取。一般情况下，方法中条件运算符和循环是可以将代码移至单独方法的一个很好的代码段，对于条件运算符，可以尝试分解条件，如果方法出现循环，可以尝试提取方法。

前言

在计算机科学中，垃圾回收（GC: garbage collection）是内存自动管理的一种方式，它并不是同 Java 语言一起诞生的，实际上，早在 1959 年为了简化 Lisp 语言的手动内存管理，该语言的作者就开始使用了内存自动管理技术。 垃圾收集和手动内存管理刚好相反，后者需要编程人员自己去指定需要释放的对象然后将内存归还给操作系统，而前者不需要关心给对象分配的内存回收问题。Java 语言使用自动垃圾收集器来管理对象生命周期中的内存，要进行垃圾收集首先需要明确三个问题：1. 哪些内存需要回收、2. 什么时候进行回收、3. 怎么进行内存回收。接下来让我们一起看看 Java 语言对这些问题是如何处理的。

哪些内存需要回收

为了方便管理和跨平台，Java 虚拟机规范规定在执行 Java 程序的时候把它所管理的内存划分为若干个不同的数据区域。这些区域都有着各自不同的用途以及创建和销毁的时间，有的数据区域随着用户线程的启动和结束而建立和销毁，有的区域会随着虚拟机进程的启动和停止而存在和销毁。更多有关运行时数据区域的内容请看 Java 运行时数据区域。
由于 Java 运行时数据区域中的 程序计数器、虚拟机栈和本地方法栈和线程的生命周期一致，随线程的启动和结束而建立和销毁。而且当我们的类结构确定了之后，在编译期间，一个栈帧需要分配内存的大小基本上也就确定下来了，这三个区域的内存分配和收回都是具备确定性的，不需要我们过多的去考虑内存回收问题。主要考虑Java 堆和方法区的内存回收的问题。