计算机领域有一句话：计算机中任何问题都可通过增加一个虚拟层解决。这句体现了分层思想重要性，分层思想同样适用于Java工程架构。

最近知识星球的球友在学习星球中的《精尽Spring Cloud Alibaba》专栏提到一个问题，相信也有很多人在线上环境遇到过，或许也因此被批过：一个集群中有某个服务突然下线，但是网关还是会去请求这个实例，所以线上就报错了，报错信...

不知道大家在项目中有没有遇到过这样的场景，根据传入的类型，调用接口不同的实现类或者说服务，比如根据文件的类型使用 CSV解析器或者JSON解析器，在调用的客户端一般都是用if else去做判断，比如类型等于JSON，我就用JSON解析...

是的，今早一到公司就收到了机器人的告警，从异常日志来看是数据库连接已关闭，然后我在解决这个问题的过程中发现了几个问题，不急，听我一一道来...

Spring的bean默认都是单例的，某些情况下，单例是并发不安全的，以Controller举例，问题根源在于，我们可能会在Controller中定义成员变量，如此一来，多个请求来临，进入的都是同一个单例的Controller对象，并对此成员变量的值进行修改...

经常会遇到这样一种情况：项目的配置文件中总有一些敏感信息，比如数据源的url、用户名、密码....这些信息一旦被暴露那么整个数据库都将会被泄漏，那么如何将这些配置隐藏呢？...

这些错误可能是因为网络波动造成的，等待过后重处理就能成功。通常来说，会用try/catch，while循环之类的语法来进行重处理，但是这样的做法缺乏统一性，并且不是很方便，要多写很多代码。然而spring-retry却可以通过注解，在不入侵...

在开发中总会遇到这样的场景，比如工单状态，流程状态，通过状态判断该执行的操作，不断改动的需求导致永无止境的 IF、ELSE 和 BREAK 子句的层次结构，当事情开始看起来太复杂时，简直就像面满池子的海洋球。...

由图可见，ConfigurationApplicationContext 实现了 ApplicationContext 接口，实现了 BeanFactory 接口。

本文的主要目标是分析、总结、归纳历史上出现过的 Spring 框架漏洞，从而尝试找出其中的潜在模式，以达到温故知新的目的。当然作为一个 Java 新手，在直接分析漏洞之前，还是会先从开发者的角度去学习 Spring 中的一些核心概...