共计 1088 个字符，预计需要花费 3 分钟才能阅读完成。
置信昨天，很多小伙伴都因为 Log4j2 的史诗级破绽忙翻了吧？
看到群里还有小伙伴说公司里还特地建了 800+ 人的群在解决 …
好在很快就有了缓解措施和解决方案。同时，log4j2 官网也是速度影响公布了最新的修复版本。各利用方也能够执行较为稳固的修复计划了。
不过我看到群里收回来的各种修复办法，还真是不难看 … 所以这里也提一下 Spring Boot 用户怎么修复最简略吧。
最简修复形式
有些小伙伴其实想到了间接通过 Spring Boot 的 Starter 去解决，所以还给 Spring Boot 提了 Issue，心愿 spring-boot-starter-log4j2 能够反对最新的 2.15 版本（提 Issue 的时候还是 rc1，当初曾经 release 了）
但相熟 Spring Boot 组件的版本机制的话，其实这个并不需要顺便发版解决。只须要加个简略配置就能够了，具体如下图：
是的，就是这么简略，只须要在 pom.xml 中像上面配置就能够了：
<properties>
<log4j2.version>2.15.0</log4j2.version>
</properties>如果您正在学习 Spring Boot，那么举荐一个连载多年还在持续更新的收费教程：http://blog.didispace.com/spring-boot-learning-2x/
后记
不晓得大家有没有发现，最近几次因为破绽影响到咱们 Spring Boot 利用的都不是 Spring Boot 原装的货色。
比方：这次的 Log4j2，其实并不是 Spring Boot 默认应用的日志组件，Spring Boot 默认应用 Logback。所以这次没有去更改日志组件的小伙伴们昨天都在群里看热闹。。。
而再之前比较严重的破绽大多都是由另外一位第三方组件引起的，置信你也猜到是谁了吧？
对的，就是 Fastjson。
Spring Boot 默认的 JSON 字符串序列化和反序列化工具是 Jackson，而并非 Fastjson。不过不晓得从什么时候开始，就开始风行 Fastjson 的计划（我记得 XML 配置时代就开始了，可能是性能思考？）。
最近 DD 这边因为还是都用原装组件，所以都没碰到这些问题，还挺舒坦的。所以，最初还是倡议大家如果没有没有碰到什么特地的性能要求，或其余原装组件无奈实现的工作时候，再去采纳其余计划来替换默认计划，这样会更加稳固。毕竟，默认计划除了 Spring 官网，整个生态也是利用最为宽泛的，它们更经得起考验。
最初，调研下，大家平时应用都替换哪些 Spring Boot 的默认组件呢？留言区通知大家吧~
欢送关注我的公众号：程序猿 DD，分享其余中央看不到的常识与思考