小小默：进无止境

Redis连接被重置错误分析及解决方案 摘要： 本文分析了"java.io.IOException: Connection reset by peer"错误的原因，指出问题主要源于Redis服务端或中间网络设备主动关闭连接。常见原因包括Redis空闲超时、连接数限制、服务重启或网络中断。通过检查Redis日志和配置(timeout、maxclients等)可定位问题根源。针对给出的Spring配置，指出了关键缺陷：过长的空闲连接驱逐时间与Redis默认超时冲突，以及废弃的参数使用。提供了

Redis连接关闭错误分析与解决方案 ERR server connection close错误通常由Redis服务器主动断开闲置连接引发，常见于Lettuce客户端。主要原因为：Redis默认5分钟空闲超时、服务器资源限制或网络问题。 解决方案： 配置连接保活：启用空闲检测（test-while-idle）和TCP Keepalive 优化超时设置：调整Redis的timeout和客户端连接池参数 添加重试机制：使用Spring Retry处理瞬断 诊断建议：检查Redis日志中的"Closin

摘要： Nginx在静态文件下载场景（性能、并发、缓存、CDN支持）上全面优于Spring Boot，适合公共大文件；而Spring Boot更适合需权限控制的私有文件。推荐混合架构：Nginx处理公共文件（配置简单高效），Spring Boot负责带鉴权的私有文件。实际选择应结合业务场景，初期可用Spring Boot快速开发，流量增长后迁移静态资源至Nginx或对象存储。测试表明，Nginx在大文件、高并发下响应更快，而Spring Boot在开发灵活性上占优。

Spring Boot线程池优化实践 本文详细介绍了Spring Boot中ThreadPoolTaskExecutor的6大优化方向：1)合理设置线程池参数，包括核心/最大线程数、队列容量等；2)自定义拒绝策略并记录日志；3)通过TaskDecorator传递线程上下文；4)集成Micrometer进行监控；5)动态调整配置参数；6)选择合适队列类型。文章提供了具体配置示例和适用场景分析，特别指出使用@Async时默认线程池的命名规则，建议为不同场景配置专属线程池。这些优化措施能有效提升系统性能、可靠性和

方法适用场景优点缺点@Async简单异步任务集成简单，适合轻量级场景需处理线程池和异常，同类调用失效消息队列分布式系统、高可靠性场景解耦彻底，支持重试和削峰维护中间件，复杂度高复杂异步流程控制灵活，支持链式调用代码复杂，需手动管理应用内事件通知松耦合，易于扩展监听器不支持分布式，依赖@Async根据实际场景选择：轻量级任务用@Async，分布式需求用消息队列，复杂流程用，应用内解耦用事件监听。

视频播放通常需要支持，需确保后端正确处理HTTPRange头，实现按需传输部分内容。

整合Spring Boot、MyBatis和ClickHouse可以让你使用Java开发的应用程序高效地与ClickHouse数据库进行交互。

是 Spring 框架中用于发送 HTTP 请求的一个工具类。虽然本身已经提供了很多功能，但在某些情况下，你可能需要对其进行更详细的配置。你可以通过创建一个配置类来实现这一点。

easyexcel使用实践总结

这里SpringBoot为3.0.5，jdk为17，kafka-clients为3.6.1

本文总结SpringBoot或者SSM体系下跨域后端处理方案。

需求背景：与客户端通信内容需要加密。客户端将请求参数进行加密，服务端对响应结果进行加密。那么对于后端而言，最方便的就是在过滤器里面对请求、响应进行统一处理了。这里需要涉及到HttpServletRequestWrapper与HttpServletResponseWrapper。# 【1】请求处理如下所示ParameterRequestWrapper 继承自HttpServletRequestWrapper ，重写获取参数的方法。```java/** * Created by jianggc

接上文[SpringBoot中事务执行原理分析（五）](https://blog.youkuaiyun.com/J080624/article/details/78264800)后，本文我们分析一下事务处理过程中的事务同步管理器`TransactionSynchronizationManager`与事务同步`SqlSessionSynchronization`。# 【1】事务同步管理器这里指的是TransactionSynchronizationManager。管理每个线程的资源和事务同步的中央委托。通常用于

本文是对[SpringBoot中事务执行原理分析（一）](https://janus.blog.youkuaiyun.com/article/details/54603669)的补充说明，我们详细分析一下如何判断Advisor与我们的service是否匹配。在前文中我们提到了**BeanFactoryTransactionAttributeSourceAdvisor**，其包含了Advice用于对我们的service进行增强实现事务效果。```csharppublic class BeanFactoryTra

接上文[SpringBoot中事务执行原理分析（四）](https://blog.youkuaiyun.com/J080624/article/details/52786286)我们分析过方法正常执行完事务提交后，本文我们继续分析目标方法抛出异常后事务的回滚流程，即 `completeTransactionAfterThrowing(txInfo, ex)`。**TransactionAspectSupport的completeTransactionAfterThrowing方法如下。**```javaprot

接上文[SpringBoot中事务执行原理分析（三）](https://blog.youkuaiyun.com/J080624/article/details/52785544)我们分析过事务信息对象的获取后，本文我们继续分析目标方法执行后事务的提交流程，即 `commitTransactionAfterReturning(txInfo);`。如下所示TransactionAspectSupport的事务提交动作交给了事务管理器来处理。```java// org.springframework.transact

接上文[SpringBoot中事务执行原理分析（二）](https://janus.blog.youkuaiyun.com/article/details/53202138)后，本文我们分析事务执行流程中的`获取事务对象 - createTransactionIfNecessary` 。也就是分析TransactionAspectSupport的invokeWithinTransaction方法中下面这行代码。```java//TransactionAspectSupportTransactionInfo

接上文[SpringBoot中事务执行原理分析（一）](https://janus.blog.youkuaiyun.com/article/details/54603669)分析后，我们本文详细跟踪下TransactionInterceptor是如何控制事务行为的。前面我们提到了，我们的service被包装为代理。当触发目标方法时首先触发了`DynamicAdvisedInterceptor`的intercept方法,我们就从这里开始跟踪。![在这里插入图片描述](https://img-blog.csdnim

如下所示，如果没有应用事务(比如事务注解或者xml配置或者编程式事务)，那么通常在PreparedStatement执行后，数据就进入了数据库，即使下一行业务代码抛出了异常也不会导致回滚。从本文开始我们开始分析事务执行原理，本文的环境是SpringBoot(+MybatisPlus)，当然在SSM的环境下其本质也是一致的。PreparedStatementHandler的update方法。................................................

本文是对[SpringBoot自动配置原理解析（四）](https://janus.blog.youkuaiyun.com/article/details/53466960)的补充，我们这里详细说明一下SpringBoot是如何将@Bean方法注册为BeanDefinition的。我们以`MybatisPlusAutoConfiguration`为例说明`sqlSessionFactory()`这个方法如何解析为BeanDefinition。```java@Bean@ConditionalOnMissing

其实本文是对[SpringBoot自动配置原理解析（二）](https://blog.youkuaiyun.com/J080624/article/details/52692159)的补充，本文我们主要研究一下`@ComponentScans`的解析过程。如下所示，在`ConfigurationClassParser`的`doProcessConfigurationClass`方法中会对@ComponentScan注解进行处理。```java// Process any @ComponentScan annot

接上文[SpringBoot自动配置原理解析（三）](https://blog.youkuaiyun.com/J080624/article/details/52756551)后，我们本文开始分析`this.reader.loadBeanDefinitions(configClasses);`。也就是`ConfigurationClassBeanDefinitionReader`的`loadBeanDefinitions`方法。也就是在这个方法里面，对前面没有处理的`@Bean注解的method`、配置类引入的 比

接上文[SpringBoot自动配置原理解析（二）](https://blog.youkuaiyun.com/J080624/article/details/52692159)我们继续往下分析。如下是ConfigurationClassParser的parse方法，当内部parse方法执行完后，就该执行`this.deferredImportSelectorHandler.process();`方法。这个时候我们的`@Bean`方法还只是`configClass`中的`BeanMethod`，还没有被注册为Bea

继[SpringBoot自动配置原理解析（一）](https://blog.youkuaiyun.com/J080624/article/details/52687492)后，我们继续分析SpringBoot如何进行自动配置的。前面我们从表现上跟踪了一下SpringBoot自动配置的大概过程，但是并没有说明处理器、环节等信息，本文从源码角度我们看一下。首先说明一下，BeanDefinition的扫描注册发生在refresh过程中的`invokeBeanFactoryPostProcessors`方法中，具体处理

本文我们开始分析SpringBoot的自动配置原理。当我们想使用某个中间件时比如Redis，我们直接引入其starter然后在application.properties做一些简单配置即可使用。这就是SpringBoot的自动配置在起作用。从本质来讲，自动配置无非就是有个处理器在启动流程的某个环节根据某个条件进行了自动扫描并注册BeanDefinition到BeanFactory中。那么这里我们要搞清楚这样几个问题：* 表现是什么？* 处理器是什么？* 哪个环节？* 如何扫描注册？* 什么时候

接上文[SpringBoot关闭时都做了哪些事？](https://janus.blog.youkuaiyun.com/article/details/73775835)，本文我们详细分析一下DisposableBean的destroy过程。`DefaultSingletonBeanRegistry`的`destroySingleton`方法。```javapublic void destroySingleton(String beanName) { // Remove a registered singl

本文我们开始分析SpringBoot关闭的时候都做了哪些事。核心流程梳理如下：* 从LiveBeansView移除掉维护的上下文* 广播ContextClosedEvent事件* 触发生命周期处理器的onClose方法，这里会stopBean,也就是触发那些Lifecycle实例的stop方法* 销毁BeanFactory中的所有DisposableBean并清空一些缓存* 关闭BeanFactory* 停止服务，这里会stop Tomcat* 将earlyApplicationListene

前面我们分析了[SpringBoot的启动流程](https://janus.blog.youkuaiyun.com/article/details/54949491)，其广播了诸多事件，本文我们尝试总结一下这些事件所带来的影响。**事件梳理**如下七种事件均是SpringApplicationEvent事件体系。* starting()方法广播ApplicationStartingEvent事件* environmentPrepared()方法广播ApplicationEnvironmentPrepar

上文[Spring中事件监听(通知)机制详解与实践](https://janus.blog.youkuaiyun.com/article/details/57411870)我们研究是Spring中的事件机制原理并进行了实践，本文我们梳理一下SpringBoot中事件广播的几个分支。# 【1】持有分支事件广播是使用SimpleApplicationEventMulticaster这个应用事件广播器进行处理的。所以我们只需要看这个实例被哪些类持有。## ① AbstractApplicationContext也

接[SpringBoot启动时都做了哪些事（三）？](https://blog.youkuaiyun.com/J080624/article/details/54950679)后，我们继续分析SpringBoot启动过程流程。本文我们分析应用上下文刷新以及后置处理。# 【1】refreshContext## ① refreshSpringApplication的refreshContext方法。```javaprivate void refreshContext(ConfigurableApplicat

接上一篇[SpringBoot启动时都做了哪些事（二）？](https://blog.youkuaiyun.com/J080624/article/details/54949491)后，我们继续分析SpringBoot启动过程流程。本文我们开始分析应用上下文的创建和配置。# 【1】创建应用上下文SpringApplication的createApplicationContext方法。如下所示如果contextClass 为努力，那么根据webApplicationType来获取上下文class类型，然后使

SpringBoot中是如何打印banner的呢？我们如何自定义banner？SpringApplication的printBanner方法如下所示，其是一个桥梁。进行了必要的判断后，获取resourceLoader 和bannerPrinter，然后将任务交给了bannerPrinter去处理。```javaBanner printedBanner = printBanner(environment);private Banner printBanner(ConfigurableEnviro.

接上一篇[SpringBoot启动时都做了哪些事（一）](https://blog.youkuaiyun.com/J080624/article/details/54949134)后，我们继续分析SpringBoot启动过程流程。SpringApplication的run方法```javapublic ConfigurableApplicationContext run(String... args) { //实例化监控 StopWatch stopWatch = new StopWatch(); //

本文环境是SpringBoot 2.2.4.RELEASE,我们尝试去跟踪研究启动流程都做了哪些事情。以main方法为入口。```javapublic static void main(String[] args) { SpringApplication.run(RecommendApplication.class, args); }```SpringApplication的run方法。```javapublic static ConfigurableApplicationCon

本文这里环境是springboot 2.2.4.RELEASE。创建WebServer是在refresh方法的onRefresh方法中实现的。其也是refresh方法体系的一个重要步骤。ServletWebServerApplicationContext的onRefresh方法。如下所示其首先调用父类的onRefresh方法初始化ThemeSource，然后调用createWebServer创建WebServer。```java@Overrideprotected void onRefresh()

# 【1】什么是跨域？## 同源策略同源策略（Sameoriginpolicy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。同源策略会阻止一个域的javascript脚本和另外一个域的内容进行交互。所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）和端口号（port）浏览器的同源策略阻止了浏览器读取不同源的资源。这种

Spring中事件监听(也有说法叫事件通知)机制，其实本质是观察者模式的应用。当某个事件发生时，其会被广播出去，监听该实践的listener就会被触发然后执行响应的动作。该模式可良好应用于程序解耦，类似消息的发布订阅。# 【1】事件、广播与监听这个模式有三元素：事件、广播与监听。## ① 事件如下图所示，事件继承自EventObject类，该类维护了事件最初发生在其上的对象-source。而我们通常自定义的事件实际应继承自抽象类ApplicationEvent。比如常见的上下文刷新事件Contex

# 【1】处理handler返回结果前置流程，在DispatcherServlet处理请求的过程最后处理结果时，会判断处理过程中异常是否存在，如果异常存在就会尝试对异常进行处理。```javaDispatcherServlet#doDispatch -->DispatcherServlet#processDispatchResult-->DispatcherServlet#processHandlerException```**处理handler的返回结果源码:**```javapriv

背景：服务端返回信息，其中某ID字段是long型，值是16位。前端拿到后再传给服务端，某ID值发生了改变。**这是因为，JS 中能精准表示的最大整数是：**```javaMath.pow(2, 53)，十进制即 9007199254740992```所以我们需要服务端返回给前端时对这种情况进行处理，本文是在springboot环境下使用fastJsonHttpMessageConverter引申介绍。# 【1】自定义MyLongSerializerAndDeserializer我们自定义M

在前面我们分析[SpringMVC常见组件之HandlerAdapter分析](https://janus.blog.youkuaiyun.com/article/details/120848435)中提到过如下过程：```javaRequestMappingHandlerAdapter.invokeAndHandle(webRequest, mavContainer);--ServletInvocableHandlerMethod.invokeAndHandle(webRequest, mavContaine