LoveSummer

平时跟RD排查问题，经常会遇到数据库连接池相关的问题，比如获取不到连接、抛异常、长时间占用无法归还、探活、性能开销等。发现不少同学对连接池仍停留在表层的一知半解，很多配置也是相互复制的，基于此，本文整理了。当我们有了连接池，应用程序启动时就预先建立多个数据库连接对象，然后将连接对象保存到连接池中。新建连接和关闭连接，操作较重，费时费力，也影响了业务请求。功能，连接从连接池借出后，长时间不归还，将触发强制关闭其。连接池最核心的功能就是连接的获取与回收。）连接，随着程序的运行，池不忙时也会保持最少3个（

所以可以得出结论：BigDecimal在计算时，实际会把数值扩大10的n次倍，变成一个long型整数进行计算，整数计算时自然可以实现精度不丢失。同时结合精度scale，实现最终结果的计算。在金融领域，为了保证数据的精度，往往会使用BigDecimal。本文就来探讨下为什么BigDecimal可以保证精度不丢失。通过debug来发现源码中的奥秘是了解类运行机制很好的方式。这个例子中，该方法传入的参数分别是：xs=236，scale1=2，ys=35，scale2=1。

现代软件开发中，状态机作为一种强大的工具，被广泛应用于各种业务场景，用以管理对象的生命周期及其状态转换。本文将深入探讨 Spring 状态机和阿里状态机。

特点没有其他依赖，下载后安装非常方便；只用修改几个参数就可以搭建起来一个集群；输入 / 输出格式为 JSON，意味着不需要定义 Schema，快捷方便；基本所有操作 (索引、查询、甚至是配置) 都可以通过 HTTP 接口进行；节点对外表现对等（每个节点都可以用来做入口） 加入节点自动负载均衡；可根据不同的用途分索引，可以同时操作多个索引；可以扩展到 PB 级的结构化和非结构化数据 海量数据的近实时处理；功能分布式的搜索引擎分布式：Elasticsearch 自动将海量数据分散到多台服务器上去存储和检索。

IoC（Inverse of Control: 控制反转）是⼀种设计思想，就是将原本在程序中⼿动创建对象的控制权，交由 Spring 框架来管理。IoC 在其他语⾔中也有应用，并非Spring 特有。IoC 容器是 Spring 用来实现 IoC 的载体， IoC 容器实际上就是个 Map（key，value）,Map 中存放的是各种对象。将对象之间的相互依赖关系交给 IoC 容器来管理，并由 IoC 容器完成对象的注⼊。这样可以很大程度上简化应用的开发，把应用从复杂的依赖关系中解放出来。

Logback 可配置多种颜色，支持：%black，%shired，%green，%yellow，%blue，%magenta，%cyan，%white，%gray，%boldRed，%boldGreen，%boldYellow，%boldBlue，%boldMagenta%boldCyan，%boldWhite，%highlight。尤其在生成日志文件的时候，这个是非常有必要的，因为日志文件必须要设置最大文件大小，如果在生成日志文件的规则内，一个日志文件生成到了最大值，那就需要生成 2 号文件。

各位看官大家好，今天给大家分享的又是一篇实战文章，希望大家能够喜欢。

Servlet 容器加载 Servlet，加载完成后，Servlet 容器会创建一个 Servlet 实例并调用 init() 方法，init() 方法只会调用一次。客户发送一个请求，Servlet 调用 service() 方法对请求进行响应，service() 方法会对请求的方法进行匹配，进入相应的逻辑层，完成请求的响应。3.初始化：通过调用Servlet的init()方法来完成初始化工作，这个方法是在Servlet已经被创建，但在向客户端提供服务之前调用。Servlet 类文件被更新后，重新装载。

最后我从官网捞了一张 Xxl-Job 架构图奈何作者不更新呐，导致这个图稍微有点老了，有点跟现有的架构对不上比如说图中的自研 RPC（xxl-rpc）部分已经替换成了 Http 协议，这主要是拥抱生态，方便跨语言接入但是不要紧，大体还是符合现在的整个的架构从架构图中也可以看出来，本文除了日志部分的内容没有提到，其它的整个核心逻辑基本上都讲到了而日志部分其实是个辅助的作用，让你更方便查看任务的运行情况，对任务的触发逻辑是没有影响的，所以就没讲了。

在发布或重启某线上某服务时（jetty8 作为服务器），常常发现有些机器的 load 会飙到非常高（高达 70），并持续较长一段时间（5 分钟）后回落（图 1），与此同时响应时间曲线（图 2）也与 load 曲线一致。注：load 飙高的初始时刻是应用服务端口打开，流量打入时（load 具体指什么可参考 http://www.cnblogs.com/amsun/p/3155246.html）。图 1 发布时候 load 飙高图 2 发布时候响应时间飙高。

您可能知道 Docker 中的所有镜像都有 Linux 内核的基础层，因此我们不需要将这部分添加到我们的镜像中，因为我们的基础镜像提供了您的应用程序所需的底层内核和依赖项。在此示例中，我们使用多阶段构建，首先在单独的层中构建 Spring Boot 应用程序，然后将构建的 jar 文件复制到最终镜像中。通过这种方式使用多阶段构建，我们可以创建一个精简的 Docker 映像，其中仅包含运行 Spring Boot 应用程序所需的依赖项和文件。通过这样做，我们可以减小图像的大小并提高应用程序的性能。

事务，就是一组操作数据库的动作集合。事务是现代数据库理论中的核心概念之一。如果一组处理步骤或者全部发生或者一步也不执行，我们称该组处理步骤为一个事务。当所有的步骤像一个操作一样被完整地执行，我们称该事务被提交。由于其中的一部分或多步执行失败，导致没有步骤被提交，则事务必须回滚到最初的系统状态。

Apache Commons 是对 JDK 的拓展，包含了很多开源的工具，用于解决平时编程经常会遇到的问题，减少重复劳动。官网网址: http://commons.apache.org。

浏览器有跨域限制，非同源策略 (协议、主机名或端口不同) 被视为跨域请求，解决跨域有跨域资源共享(CORS)、反向代理和JSONP的方式。本篇通过 SpringBoot 的资源共享配置 (CORS) 来解决前后端分离项目的跨域，以及从原理上去解决跨域配置不生效的问题。

基础使用。

Spring Boot的日志详解日志框架的介绍Logback是由log4j创始人设计的另一个开源日志组件,官方网站： http://logback.qos.ch。它当前分为下面下个模块：logback-core：其它两个模块的基础模块logback-classic：它是log4j的一个改良版本，同时它完整实现了slf4j API使你可以很方便地更换成其它日志系统如log4j或JDK14 ...

Spring 的 JdbcTemplate.batchUpdate() 本身并不会影响性能，实际上 SQL 语句和 MySQL 数据库的处理方式才是决定因素。要改善性能，可以使用 JDBC 的批处理来批量执行 SQL 语句，或使用 MySQL 的多值插入来优化批处理。

Java 中的接口的目的是定义公开的 API，而不是实现方法细节，所以在 JDK8 以前都不支持默认和静态方法。但是出于便捷性的考虑，JDK8 中支持方法的默认实现，这样当一个接口有大量实现类的情况下，可以在不破坏原有实现的前提下迭代 API。JDK8 中接口类的默认实现解决了模型抽象中的很多问题，随之而来的是在接口中的默认方法如果需要共享一些代码段，只能将这些代码段抽象出一个新的函数。如果这个函数是静态的（JDK8 支持接口中定义静态函数），那么在函数里无法访问其他非静态 API；

虽然平时大部分工作都是和Java相关的开发, 但是每天都会接触Linux系统, 尤其是使用了Mac之后, 每天都是工作在黑色背景的命令行环境中. 自己记忆力不好, 很多有用的Linux命令不能很好的记忆, 现在逐渐总结一下, 以便后续查看.

JavaMail是由Sun定义的一套收发电子邮件的API，不同的厂商可以提供自己的实现类。但它并没有包含在JDK中，而是作为JavaEE的一部分。厂商所提供的JavaMail服务程序可以有选择地实现某些邮件协议，常见的邮件协议包括：SMTP：简单邮件传输协议，用于发送电子邮件的传输协议；POP3：用于接收电子邮件的标准协议；IMAP：互联网消息协议，是POP3的替代协议。这三种协议都有对应SSL加密传输的协议，分别是SMTPS，POP3S和IMAPS。

在Spring中大量使用策略模式来简化if/else代码,比如Spring Security 的各种等等，但是实现方式过于麻烦，使用重复套路来实现。

在实际工作中当指定查询数据过大时，我们一般使用分页查询的方式一页一页的将数据放到内存处理。但有些情况不需要分页的方式查询数据或分很大一页查询数据时，如果一下子将数据全部加载出来到内存中，很可能会发生 OOM(内存溢出)；而且查询会很慢，因为框架耗费大量的时间和内存去把数据库查询的结果封装成我们想要的对象（实体类）。在业务系统需要从 MySQL 数据库里读取 100w 数据行进行处理，应该怎么做？

本节主要讲了实现IOC的几个核心的组件BeanDefinitionReader和ClassPathBeanDefinitionScanner：读取资源，生成BeanDefinitionBeanDefinitionRegistry：存储BeanDefinitionDefaultListableBeanFactory：IOC容器，同时实现了BeanDefinitionRegistry接口。

我们公司作为一个面向银行、金融机构的TO B类企业，频繁遇到各个甲方爸爸提出的国产化数据库的改造需求，包括OceanBaseTiDBgeldenDB等等。每次适配都需要投入大量的人力进行测试工作，那么有没有更高效、低成本的方式去解决这个问题呢？本文就介绍一种快高效、可复用的解决方案——对数据访问层做单元测试。本文分享了基于项目中针对数据访问层进行单元测试的一种方式，这种方式只注入mybatis相关的bean，快速高效的对不同类型的数据库进行测试，保证程序的正确性。

一般情况下，Spring通过反射机制利用bean的class属性指定支线类去实例化bean，在某些情况下，实例化Bean过程比较复杂，如果按照传统的方式，则需要在bean中提供大量的配置信息。所有的扩展接口，以及各个扩展点的使用场景。使用场景：用户可以扩展这个类，来为要实例化的bean作一个代理，比如为该对象的所有的方法作一个拦截，在调用前后输出一行log，模仿。可以看到，该类用于执行各种驱动接口，在bean实例化之后，属性填充之后，通过执行以上红框标出的扩展接口，来获取对应容器的变量。

虽然我们在日常开发中，Spring Boot 使用非常多，算是目前 Java 开发领域一个标配了，但是小伙伴们仔细想想自己的面试经历，和 Spring Boot 相关的面试题都有哪些？个人感觉应该是比较少的，Spring Boot 本质上还是曾经 SSM 那一套，只是通过各种 starter 简化了配置而已，其他都是一模一样的，所以 Spring Boot 中很多面试题还是得回归到 Spring 中去解答！

首先，从名字上看，这两个注解意义特别接近，就是自动配置包，自动配置包的目的是能让系统扫描到包内的 Bean；则是组件扫描，这个松哥在之前的教程中也多次提到过了，就不再赘述了，所以这里就有一个问题，这两个注解有啥区别？

如图是一个简化的下单流程，首先是提交订单，然后是支付。支付的话，一般是走支付网关（支付中心），然后支付中心与第三方支付渠道（微信、支付宝、银联）交互。支付成功以后，异步通知支付中心，支付中心更新自身支付订单状态，再通知业务应用，各业务再更新各自订单状态。这个过程中经常可能遇到的问题是掉单，无论是超时未收到回调通知也好，还是程序自身报错也好。总之由于各种各样的原因，没有如期收到通知并正确的处理后续逻辑等等，都会造成用户支付成功了，但是服务端这边订单状态没更新。

FullGC 一天超过一次肯定就不正常了。发现 FullGC 频繁的时候优先调查内存泄漏问题。内存泄漏解决后，jvm 可以调优的空间就比较少了，作为学习还可以，否则不要投入太多的时间。如果发现 CPU 持续偏高，排除代码问题后可以找运维咨询下阿里云客服，这次调查过程中就发现 CPU 100% 是由于服务器问题导致的，进行服务器迁移后就正常了。数据查询的时候也是算作服务器的入口流量的，如果访问业务没有这么大量，而且没有攻击的问题的话可以往数据库方面调查。

根据以上机制，回到本问题，假如这台 Proxy 机器的众多 MQ 消费者线程中有任意一个被卡住，那么整个 queue 的消费位点将永远停留在被卡住的消息对应的 offset。Tip：MQ 拉消息的机制是，拉到的消息会先存放在内存中容量为 1000 的 cache 中，然后这些内存中的消息将被消费者线程消费。至此，Proxy 系统个别机器 MQ 堆积严重的问题根因找到：该机器的某个消费者线程在通过 HTTP 下载图片时一直卡住，导致整个 queue 的消费位点无法往前推进，从而持续堆积。

前面的知识表明，单元测试就是对一个系统中的某个最小单元的逻辑正确性的测试，通常是对一个方法来进行测试，因为只测试逻辑正确性，所以这个测试是独立的，不与任何外界环境相关，比如不需要连接数据库，不访问网络和文件系统，不依赖其他单元测试。但是现实的业务逻辑中往往有很多复杂错综的依赖关系，比如你想对 Service 进行单元测试，那么它要依赖一个数据库持久层的 Repository 对象，这时候就难办了，若创建了一个 Repository 便连接了数据库，连接了数据库便不是一个独立的单元测试。

我在研究 HikariCP（一个数据库连接池）时无意间在 HikariCP 的 Github wiki 上看到了一篇文章（即前面给出的链接），这篇文章有力地消除了我一直以来的疑虑，看完之后感觉神清气爽。故在此做译文分享。

我们深知在操作 Java 流对象后要将流进行关闭，但是现实的情况却往往不尽人意，原因是每个开发者的写法可能不尽相同，不同的写法导致出现各种千奇百怪的问题，下面我们一起来看看几种关闭流的代码案例！try {// ...操作流代码// 依次关闭流try {try {// 此处会报 java.io.IOException: Stream Closed 错误按照先后顺序关闭文件流，这种写法下，有可能会报错误。原因是依赖于，如果直接关闭流，再次关闭。

应用启动速度主要的瓶颈在于 bean 的初始化过程，本文提供了启动速度的一个探索方向。如果你的系统启动耗时 250s 以上，文章思路应该可以帮到你。

多个并行的类实现相似的代码逻辑。我们可以考虑提取相同逻辑在父类中实现，差异逻辑通过抽象方法留给子类实现。对于相同的流程和逻辑，我们还可以借鉴模板方法模式将其固定成模板，保留差异的同时尽可能避免代码重复。// 若子类没有实现该方法，则不进行数据校验在上面的代码中，是一个抽象类。该类提供了一个方法，它定义了导入数据的整个流程。具体而言，该方法首先从文件中读取原始数据，然后对数据进行校验，最后将数据保存到数据库中。其中，和方法是抽象的，由子类来实现。

我们接触的注解主要分为以下两类运行时注解：通过反射在运行时动态处理注解的逻辑编译时注解：通过注解处理器在编译期动态处理相关逻辑平时我们接触的框架大部分都是运行时注解，比如：@Autowire @Resoure @Bean 等等。那么我们平时有接触过哪些编译期注解呢，@Lombok等等像这些编译时注解的作用都是自动生成代码，一是为了提高编码的效率，二是避免在运行期大量使用反射，通过在编译期利用反射生成辅助类和方法以供运行时使用。那这些编译器注解都是如何运行的呢?又是怎么自动生成代码的呢？

Spring Boot提供了一个 @SpringBootTest 注解，用在单元测试类上以启用支持Spring Boot特性的单元测试，如果使用的是JUnit 4，那么测试类上还需要额外的@RunWith(SpringRunner. class)注解，然后在测试类方法上添加 @Test 注解即可，每一个 @Test 注解修饰的方法就是一个单元测试方法。测试当前应用下的 /user/get 接口，传入对应的用户名参数，最后检查请求状态是否OK（200），响应的内容是否和预期一致，测试结果如下图所示。

这条实践是我根据实际项目中的经历总结出的。Spring Boot项目本身使用和集成了大量的开源项目，它帮助我们维护了这些第三方依赖。但是也有一部分在实际项目使用中并没有包括进来，这就需要我们在项目中自己维护版本。如果在一个大型的项目中，包括了很多未开发模块，那么维护起来就非常的繁琐。怎么办呢？事实上，Spring IO Platform就是做的这个事情，它本身就是Spring Boot的子项目，同时维护了其他第三方开源库。

并发编程是一项非常重要的技术，无论在面试，还是工作中出现的频率非常高。并发编程说白了就是多线程编程，但多线程一定比单线程效率更高？答：不一定，要看具体业务场景。毕竟如果使用了多线程，那么线程之间的竞争和抢占cpu资源，线程的上下文切换，也是相对来说比较耗时的操作。你在哪来业务场景中使用过多线程？怎么用的？踩过哪些坑？今天聊聊我之前在项目中用并发编程的12种业务场景，给有需要的朋友一个参考。

这里提到了 ConfigurationClassPostProcessor，实现了 BeanDefinitionRegistryPostProcessor 接口。它是一个非常非常重要的类，甚至可以说它是 Spring boot 提供的扫描你的注解并解析成 BeanDefinition 最重要的组件。