Java 搬运工 & 终身学习者。

前言

在日常工作中，经常要判断一个元素是否在一个集合中。假设你要向浏览器添加一项功能，该功能可以通知用户输入的网址是否是恶意网址，此时你手上有大约 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 堆和方法区的内存回收的问题。

前言

现在流行的微服务体系结构正在改变我们构建应用程序的方式，从单一的单体服务转变为越来越小的可单独部署的服务（称为微服务），共同构成了我们的应用程序。当进行一个业务时不可避免就会存在多个服务之间调用，假如一个服务 A 要访问在另一台服务器部署的服务 B，那么前提是服务 A 要知道服务 B 所在机器的 IP 地址和服务对应的端口，最简单的方式就是让服务 A 自己去维护一份服务 B 的配置（包含 IP 地址和端口等信息），但是这种方式有几个明显的缺点：随着我们调用服务数量的增加，配置文件该如何维护；缺乏灵活性，如果服务 B 改变 IP 地址或者端口，服务 A 也要修改相应的文件配置；还有一个就是进行服务的动态扩容或缩小不方便。
一个比较好的解决方案就是 服务发现（Service Discovery）。它抽象出来了一个注册中心，当一个新的服务上线时，它会将自己的 IP 和端口注册到注册中心去，会对注册的服务进行定期的心跳检测，当发现服务状态异常时将其从注册中心剔除下线。服务 A 只要从注册中心中获取服务 B 的信息即可，即使当服务 B 的 IP 或者端口变更了，服务 A 也无需修改，从一定程度上解耦了服务。服务发现目前业界有很多开源的实现，比如 apache 的 zookeeper、 Netflix 的 eureka、hashicorp 的 consul、 CoreOS 的 etcd。

前言

做过 Java 开发的同学都知道，JVM（Java 虚拟机） 是 Java 实现的基础，虽然在平时工作中真正运用到的时候可能并不多，但是一个程序员想要上升到高级层次，那就必须知道 Java 到底是怎么运行的，这就有必要去学习了解 JVM 的相关知识了。学习 JVM 可以能更深入的理解 Java 这门语言，可以清楚知道Java程序是如何执行的以及为未来排查线上问题打下坚实的基础。接下来我们看看 2020 年的 JVM 生态报告和最新趋势，值得我们每个 Java 开发者去关注了解。

JDK 厂商占比

Oracle JDK 和 Open JDK 加起来占比将近 60%，其中 Oracle JDK 占比略多一些，Oracle JDK 和 Open JDK 都是市场上的热门选择，我们看看二者之间的一些差异。Oracle JDK 更多的关注稳定性，更适合企业级用户，而 Open JDK 相对而言没有那么稳定，它会经常发布一些新特性。Oracle JDK 支持长期发布的更改，而 Open JDK 仅支持计划和完成下一个发行版，还有一个就是 Oracle JDK 是根据 二进制代码许可协议 获得许可，而 Open JDK 是根据 GPL v2 许可获得许可。使用 Oracle 平台时会产生一些许可影响。如 Oracle 宣布的那样，在没有商业许可的情况下，在 2019 年 1 月之后发布的 Oracle Java SE 8 的公开更新将无法用于商业，商业或生产用途。但是，Open JDK 是完全开源的，可以自由使用。

前言

在互联网时代，我们的应用都是分布式系统，部署在 N 台机器上。说到分布式系统我们就不得不说分布式系统的祖先——集中式系统。它和分布式系统是两个完全相反的概念，集中式系统就是把所有的程序和功能都放到一台主机上，从而对外提供服务。集中式系统的优点就是容易理解、维护方便，它的的弊端也很明显，如果这个主机出故障了那么整个系统就崩溃了。著名投资家巴菲特有个关于投资的名言：

不要把鸡蛋放在一个篮子里

对于我们的系统而言也是如此，我们不可能保证主机永远不坏、也无法保证自己的程序永远不会出 bug，所以问题是无法避免的，我们只能把“鸡蛋”分散到不同的“篮子”里，降低系统出故障的风险，这就是我们为什么需要分布式系统的原因之一。使用分布式系统的另一个理由就是扩展性，毕竟单台主机都会有性能的极限，分布式系统可以通过增加主机数量来实现横向水平性能的扩展。接下来我们看看分布式系统中的一个基本定理——CAP定理。

前言

相信做 Java 开发的朋友们绝大部分人应该都是用 IntelliJ IDEA 作为开发工具，没用过的朋友们建议将你的开发工具换成这个，关于它的优点可以去 Google 一下，我之前都是用 Eclipse 作为开发工具，自从用过一次 IDEA 之后就再也回不去了。。。今天早上更新（作死）了一下 IDEA 到最新版（2019.3.1），安装完毕之后进入就提示说之前的激活码失效了，经过一顿搜索之后终于成功激活了，在此记录一下激活过程。

前言

在上篇 Java 反射机制（一） 介绍了一些 Java 反射相关的常用 API ，在知道了如何去使用反射之后，作为一个合格的工程师，下一步肯定是要去了解它的如何实现的，我们今天就来看看在 JDK 源码中是如何去实现反射的(PS:以下源码分析基于 JDK1.8)。

Field 类 set 方法的实现

Field 类的 set 方法是在运行时用来动态修改一个类的属性的值，进入到 Field 类的 set 方法的源码如下：

1
2
3
4
5
6
7
8
9
10
11

public void set(Object obj, Object value)
        throws IllegalArgumentException, IllegalAccessException
{
    if (!override) {
        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
            Class<?> caller = Reflection.getCallerClass();
            checkAccess(caller, clazz, obj, modifiers);
        }
    }
    getFieldAccessor(obj).set(obj, value);
}

首先根据 override 判断是否需要检查字段的访问权限，然后通过 getFieldAccessor 方法获得一个 FieldAccessor 字段访问者对象，最后调用的是 FieldAccessor 类的 set 方法进行下一步操作的，FieldAccessor 是一个接口，定义了对字段的一些操作，该接口有如下一些实现类：