Smallc0de的博客

前言最近有一个需求，要调用外部API满足业务逻辑，然后就用到了重试机制，又联想到不止API，其实很多中间件，比如Reids、各类MQ、Kafka，这些涉及到连接失败的读取写入需求都应该有重试机制。虽然最终需求使用了Spring自带的Retry机制，但是这一套还是太重了，思考了下就写了一个简易Retry功能分享出来。主要是利用Java的lambda表达式和线程接口实现有返回值和无返回值的重试。代码public class Retry { public static <T> T re

前言项目开启立即启动定时任务是很多项目都会遇到的一个需求，如何利用Java提供的函数优雅的写出来，则十分考验一个猿人的功底。Supplier + ScheduledExecutorServiceJava8中给我们提供了一系列的函数式接口，能够活用这些函数式接口减少代码的冗余，使得代码更加易读就十分考验开发的功底，今天结合一个Run起来就批量启动的定时任务项目需求，做一个Supplier + ScheduledExecutorService的组合，直接贴代码供大家参考。先简单写两个任务类作为模拟定时启

前言今天在测试环境上遇到这个问题，但是本地无法模拟出来这个问题，且网上解决办法完全不可参考，因此留下此文帮助不知所错的各位小伙伴们。本文涉及到的代码皆是伪码，涉及到的类也都是临时举例所用，只是提供一个追查类似问题的思路。首先当然要说一下，这个原因大概率还是Spring-JPA的@ManyToOne的注解的引发，网上有大把的关于如何强制持久化的例子，但是大部分都是告诉大家直接使用@ManyToOne(cascade = {CascadeType.PERSIST,CascadeType.MERGE})设置就好

前言本篇博客记录一个Spring JPA报错的解决方案。这个报错源自于一个需求的的改动，由于原始的接口执行过于缓慢，所以要改造成为异步通知模式，也因此遇到了这个报错，浪费了一上午时间。情景还原由于涉及到公司内部代码不便展示，以伪码还原整个过程。首先先把原本的结构模拟出来，以下类、方法皆为虚构，用于描述问题：@Entitypublic class Student{ @Id private long id; private String name; @ManyToOne priavte Sc

很久没有更新Kafka API相关的文档了，因为笔者工作变动Kafka这部分内容在工作中接触的就相对于之前少了一些。但架不住kafka官方还是一如既往的勤奋，官方操作Scram账户的创建与删除这部分已经更新了好久了，这次也算是填坑吧，主要就是针对alterUserScramCredentials方法做一个功能说明和demo。给网上少之又少的Kafka API中文使用教程做个增补，本次基于Kafka API 2.8.0，同时适用于2.7.0版本。

前言考虑到之前写的博客太过于偏重理论性，这篇博客是Java线程的一个小的应用实例。我们的例子中会应用到线程中的wait，notifyAll，synchronized，volatile等等线程方法和关键字，来实现这个功能，也可以更好地让大家体会到这些线程相关的理论内容，在实际运行中有什么样子的表现。最后也会用Semaphore去从另一个思路实现相同的功能，用来提供另一种思路。更多线程知识内容请点击【Java 多线程和锁知识笔记系列】场景场景大意是：现在有三个线程，线程t1输出A，线程t2输出B，线程t3

笔者在【synchronized 用法与原理分析】一文中详细的讲解了synchronized的原理和用法，但是最近发现其实深究起来有些细微的方面还是不够牢固，比如synchronized锁住this，锁住普通对象，类锁等等，在实际使用中的具体表现并没有一个直观的展示。因此这篇博客就是对这部分内容进行一个展示，从实例出发来探究synchronized锁的种种表现，希望各位对synchronized有一个立体的认识。

最近一段时间在研究算法，不可避免的就会涉及到Java中对数字的各种左移与右移的运算，同时这部分内容在JDK源码中也涉及不少，尤其是List，Map的扩容机制都使用到了这部分，但是在查找相关资料的时候，发现很多博客写的太过于理论，并不利于理解，笔者希望能从代码上给大家提供一个新的理解思路。博客将会从正负数，int，long等几个角度去分别说明其中的区别。

前言发现网上好多帖子内容过于陈旧，基本上没啥参考价值。其实这个问题很好解决，写出来共给后来人一个新的参考。笔者用Eclipse+Maven打包的项目是SpringBoot项目，打包出来含有依赖的Jar能够直接用java -jar xxx.jar命令运行。Maven打包成为含依赖的Jar包第一步：Maven Clean 等待运行完，显示SUCCESS。第二部：Maven Generate-Sources 等待运行完，显示SUCCESS。第三步：Maven Install 等待运行完，显示SUCC

由于Apache官方一直没有提供AdminClient中对账户这一块的操作，因此这部分大多数时候都是用命令行去操作的，但是命令行毕竟不是很方便。为了解决这部分问题，笔者去读了Kafka Scala的源码，从中梳理出来这部分内容供给大家参考。

主要提供一个实例说明给Kafka集群配置SSL/SALS双重安全认证，包括配置文件内容，验证的例子，报错处理等等内容。

主要介绍了如何查看Kafka中账户的权限，以及权限的内容

介绍功能如下：查询Group ID列表，指定Group ID查询信息，创建Group ID并绑定到账户，删除Group ID并解除账户绑定等等。

前言好久没有更新AdminClient的博客，主要是一直在摸索怎么用的，官网写的太简略，只能一边研究官网，一边研究源码注释。而且KafkaAPI更新速度飞一样，版本兼容也是个问题，刚刚知道怎么用的，版本过时了又得看新的。而且有些功能API没有提供，就只能去钻研Scala源码，好在和Java差不了很多，虽然不会写，但是勉勉强强能读懂，对于笔者正在开发的项目来说真是崩溃了。所以等笔者把这些内容整理整理，让大家操作Kafka更加顺手。下面就是开始博客正文了，更多内容请点击【Apache Kafka API Ad

本篇简单的介绍了ReentrantLock，ReentrantReadWriteLock，CountDownLatch，CyclicBarrier，Semaphore等等官网解释，以及使用场景和例子

之前说锁的升级的时候，说到了自旋锁会空转几次尝试等待获取资源，其实这一系列的动作是有一个规范的这个规范叫做同步发生器AbstractQueuedSynchronizer ，简称AQS。同步发生器是用来构建锁用的，可以说是Java中同步组件的基础，在Java JDK的JUC包中：java.util.concurrent。我们常用的ReentrantLock，Semaphore等等用的都是这样一个架构，可以说是这些Lock工具的一个基础。

前言很多同学都在学习Java的过程中听说过单例模式，或者在面试中遇到过类似的问题。单例模式算是老生常谈的问题了，其实就是一句话能说清楚事情：所谓单例模式，就是实例化过程中只实例化一次。无论有多少线程来访问，都只实例化一次，多个线程调用已经实例化好的对象，而不是重新创建一个。虽说简单但是还是有不少细节要深究一些，比如前面有些文章里说的DCL就是单例模式的实例之一。为什么要有单例模式既然要说单例模式还是从零开始，设想这样一个场景：远程办公，有一个任务文档要写，很多同事必然要打开这个文档去输入内容，如果给每

前言在任何编程语言中，多线程操作同一个数据都会带来数据不一致的问题，这是由于在多线程的情况下CPU分配时间片并不是按照线程创建顺序去分配的，具有一定的随机性。一个任务被首先创建出来，并不意味着这个特定的任务一定会首先执行，为了解决并发状态下数据不一致的问题，就有了Lock、synchronized、volatile等等一系列的解决方法。在这一系列之前的博客【Java 线程知识笔记 (五) synchronized 用法与原理分析】中我们已经详细的解析过synchronized实现原理和使用方法，本篇则会侧

说到Java的运行，就离不开进程和线程，这两个概念其实也是所有编程语言的核心。无论是什么语言，归根结底就是在操作CPU，让CPU分配相应的计算资源给应用程序。而线程就是CPU能够调度和分派的基本单元，多个线程组合在一起做一件事情就变成了进程。既然有了多线程，那么如何保证数据一致性，保证线程有序性就成了Java编程中的重中之重，因此又有了锁的概念。可以说线程和锁是Java编程中基础的基础，但是由于其不好理解因此很少会被当作Java的基础去介绍和讲解。

本篇主要说了锁的概念，锁在对象头中格式，锁的状态，自旋锁，锁的升级等等内容。

说到Java就必然会考虑到线程的问题，无论工作中学习中有没有直接接触过多线程开发，手写过线程调用，在这个底层已经到了多核多缓存的硬件时代，多线程是任何码农都绕不过的一个事情。只要有线程，就会有并发的现象，也同时会产生数据不一致。那么对于需要使用同一个数据的两个线程，就会产生冲突，那么就引出了锁的概念。锁有很多种本篇会针对性的说下synchronized这个关键字是如何保证线程的有序进行。

前言上一篇我们从源码里面探究了一个线程在线程池中是如何执行的，由于线程池有一个很大的框架，仅仅通过这点东西就说明白线程池，尤其是对于初学者来说更是难以理解。因此这篇将会对源码讲解中遗漏的一些内容，比如线程池的状态，以及线程池中线程是在哪里创建的等等做一个补漏，同时对线程池的基本内容进行一个概念性的阐述。

基本上已经把Java中线程有关的基础知识说了个大概。考虑到开启线程是一个开销很大的事情，如果每个子线程都在使用的时候做初始化等待分配等等一系列的事情，就会非常的影响程序的响应速度。为了解决这个问题，Java也是从1.5开始提出了线程池(ThreadPool)的概念。本篇就会着重对线程池进行一个讲解。

本篇把有关Callable接口，Future接口和FutureTask类是如何使用的，以及结果集在底层是如何获取的，线程在FutureTask中的状态划分等等内容，从源码层面做了一个详细的分析。

说到Java的运行，就离不开进程和线程，这两个概念其实也是所有编程语言的核心。无论是什么语言，归根结底就是在操作CPU，让CPU分配相应的计算资源给应用程序。而线程就是CPU能够调度和分派的基本单元，多个线程组合在一起做一件事情就变成了进程。线程可以说是Java中基础的基础，但是由于其不好理解因此很少会被当作Java的基础去介绍和讲解。这篇博客会对Java中线程的使用和部分方法源码做一个整理，对自己是一个基础巩固，顺带希望能帮助其他人更好的理解线程。

前言上篇【SpringBoot深度探究（九）源码探究启动流程之三】说完了Tomcat启动以后，到目前为止SpringBoot的启动流程就剩下一个问题没有解决，那就是如何把DispatcherServlet和Spring环境联系起来的，那么本篇博客将会把这个问题做一个讲解。更多Spring内容进入【Spring解读系列目录】。DispatcherServletAutoConfiguration和之前模拟的一样，首先SpringBoot在启动中new出来，然后再把DispatcherServlet注册到S

前言上一篇【SpringBoot深度探究（八）源码探究启动流程之二】主要说了SpringBoot中如何应用的观察者模式，如何使用广播引起相关监听器兴趣的以及监听器的反应。本篇将会探究SpringBoot是在何时启动的Tomcat以及相关Web环境初始化的。更多Spring内容进入【Spring解读系列目录】。SpringApplication.run接着上篇的run()方法里面的内容，从try-catch块讲起。public ConfigurableApplicationContext run(St

前言上一篇【SpringBoot深度探究（七）源码探究启动流程之一】主要介绍了SpringApplication在构造方法里做了一些必要的初始化，其中最重要的点就是把初始化器类和监听器类全部都加载进去了。本篇将会接着这一进程继续探索run()方法在后面做的事情。但是要说明的是启动流程将主要针对于如何走的Spring主流程，因为SpringBoot每次发布事件都会把所有的Listener循环一遍，以找到对应此事件感兴趣的Listener，全写出来会使得博客太跳，不利于把控整个主流程。各个Listener起了

前面已经罗嗦了三篇博客用来介绍观察者模式的理论以及实现，都是为了本节讲解SpringBoot启动流程的源码做准备的，因为在阅读SpringBoot源码启动流程的时候发现spring公司的大神们在设计SpringBoot的时候，把观察者模式用到了极限。如果不把观察者模式讲清楚，那么读起来SpringBoot的源码会非常的痛苦。那么既然观察者模式已经搞清楚了，下面就开始正式进入SpringBoot的源码探究的过程。

前言前两篇博客【观察者设计模式的演进】和【JDK观察者模式探究】深度讲了观察者模式的实现和作用，相信很多同学都知道SpringBoot是基于Spring Framework的一套东西做出来的。之所以SpringBoot能够做到非常简便的启动，很大一部分功劳应该属于Spring Framework中提供的Listener-Event功能。所以这篇博客就是要看下Spring的Listener-Event到底是有什么功能，以及它在SpringBoot的启动中扮演了什么角色。Spring EventsSpri

前言上一篇博客【观察者设计模式的演进】详细的讲解了观察者模式的概念以及如何从零开始实现一个观察者模式，那么这一篇的主要内容就是JDK中观察者设计模式的实现。通过对比观察者模式，JDK观察者模式，以及Spring对观察者模式的应用去研究SpringBoot中的事件编程模型是怎样的一个过程。场景回顾上一篇做了一个小场景去实施观察者模式，再回顾一下：假设一个花盆里有一朵花(Flower)，花朵的旁边有两个测试人员小红(XiaoHong)和李华(Lihua)。当这朵花开放(bloom)的时候小红会开心的笑(l

前言SpringBoot和SpringMVC有一个很大的改进，就是SpringBoot基于SpringMVC做了很多的事件监听模型。要弄清楚什么是Spring中的事件监听模型，首先要说明白什么是观察者设计模式。所以本篇将会从一个例子详细讲解观察者设计模式的演进。场景模型为了说清楚什么是观察者设计模式，先讲一个小的场景。场景很简单：假设一个花盆里有一朵花(Flower)，花朵的旁边有两个测试人员小红(XiaoHong)和李华(Lihua)。当这朵花开放(bloom)的时候小红会开心的笑(laugh)，但

这篇博客是对【@Resource 源码解析】做的另一个补丁。主要会讲解在使用@Resource的时候发生的expected single matching bean but found 2异常在源码层面是一个怎么样子的过程。为什么要用@Resource讲解，因为这个注解比较好模拟异常的发生，实际上@Autowired发生的原理也是一样的。

这篇博客是对【@Resource 源码解析】做的一个补丁。主要会讲解在使用@Resource的时候发生的is expected to be of type 'xxx' but was actually of type 'xxx'异常在源码层面是一个怎么样子的过程。为什么要用@Resource讲解，因为这个注解比较好模拟异常的发生，实际上@Autowired发生的原理也是一样的。

本篇博客的主要内容是去从源码追踪探究@Resource是为什么被称为byName注入的。

之前博主已经通过例子还有部分源码阐述了Spring自动装配的原理，模型以及自动装配的技术。简单来说就是四个模型：AUTOWIRE_NO，AUTOWIRE_BY_TYPE，AUTOWIRE_BY_NAME，和AUTOWIRE_CONSTRUCTOR。两种实现技术：@Autowired和@Resource。本片博客的内容将会从源码角度解析，为什么很多人都说@Autowired是ByType自动装配。

最近在读SpringBoot源码的时候发现了一个变化，根据博主以往的经验来说，Spring系列用Log4j 2.x作为日志记录的工具是板上钉钉的事情。但是再跟踪调试最新版的SpringBoot的时候，却发现其日记记录系统变成了SLF4J，追踪一下版本发现早在SpringBoot 2.1.18.RELEASE就已经做了修改，真实三日不见当刮目相看，更新的太快了。那么本篇就从源码里面看下新版本到底和旧版本有什么区别。这里版本的对比是2.1.1.RELEASE和2.3.5.RELEASE最新版本的对比。

上一篇【SpringBoot深度探究（一）】模拟了一个SpringBoot启动Tomcat的过程，其核心技术就是Servlet3.0提供的SPI做的服务增强。这篇将会继续探究SpringBoot的其他核心功能。比如这篇博客要说的Multipart Resolver，主要用来做上传功能的模块，我们将会从Spring官网的使用样例说到为什么Spring要这样做。

SpringBoot是目前最广泛的Web开发框架，其极度方便的开发特性得到市场的充分认可。这一系列的博客会进行一个详细的探讨，包括SpringBoot的原理模拟，SpringBoot源码解读，以及SpringBoot重要功能的官方文档的解读。俗话说了解一个组织就到打入这个组织内部，毕竟我就看一眼嘛。所以笔者会在Spring框架下，模拟一个SpringBoot的基本功能入手，然后在和SpringBoot的源码做对比，深度学习一下SpringBoot。

上一篇最后留了一个问题。当启动Tomcat的时候，Tomcat自动去访问了Spring框架中实现了WebApplicationInitializer接口的类。那么这个问题就是Tomcat是怎么知道Spring中有一个实现类去初始化各种Web环境的呢？本篇就从源码里探究一下这个是怎么做到的。