Java

为什么三个生态面对同一个"版本冲突"问题，给出了截然相反的答案？ 那个让我加班到凌晨三点的依赖冲突 去年一个周五晚上，生产环境突然爆出 NoSuchMethodError。排查了两个小时，最终发现是一个同事在公共模块里升级了 Guava，而另一个模块还在用旧版 API。Maven 的"就近原则"在本地构建时选了新版，到了 fat jar 打包时又选了旧版——同一个项目，两种行为，取决于你从哪个子模块触发构建。 那天晚上我一边修 bug 一边想：为什么 Go 的项目从来没遇到过这种事？为什么前端项目几百个 node_modules 嵌套也没炸？ 答案藏在三个生态对同一个问题的不同哲学选择里。 三种哲学：强约束、隔离共存与极简主义 Maven 的"大一统"：宁可痛苦，不要歧义 Maven 的核心信条是一个项目里，同一个库只能有一个版本。 这听起来很武断，但背后有深刻的理由。Java 运行在 JVM 上，类加载器的行为决定了：如果同一个类（全限定名相同）被两个不同版本的 jar 同时加载，轻则方法签名不匹配抛 NoSuchMethodError，重则序列化反序列化直接炸掉。这不是"可能出问题"，而是"一定会出问题"。 所以 Maven 选择了最暴力的策略——Dependency Mediation（依赖裁决）： <!-- Maven 的冲突裁决逻辑（简化版） --> <!-- 1. 路径最短优先 --> <!-- 2. 路径相同时，pom.xml 中先声明的赢 --> <!-- 3. 你可以在 dependencyManagement 里强行指定 --> <dependencyManagement> <dependencies> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>33.0.0-jre</version> <!-- 我说用哪个就用哪个 --> </dependency> </dependencies> </dependencyManagement> 这种策略的代价是升级是一场战争。你不能只升级直接依赖，还必须处理所有传递依赖的兼容性。大厂的 Java 项目每年花大量时间在"依赖版本升级周"上，这不是笑话，是真实的企业级成本。 ...

问题现象 普通 SQL 正常，stg 环境没发现异常。但生产环境用户反馈：超长 SQL（超过 1MB）会触发 400 报错。 恰好生产环境的用户有很多那种业务逻辑复杂、拼接出来的超长 SQL。 排查过程 第一步是对比。把报错的 SQL 和不报错的 SQL 摆在一起看，唯一的共同点就是——长。 短 SQL 跑得好好的，长到一定长度就 400。这不是 SQL 语法问题，是传输层的问题。 根因 查到最后，原因是这样的： 安全合规要求，把普通的 Statement 升级为 PreparedStatement。因为普通 Statement 有 SQL 注入风险，安全团队要求整改。 Presto 驱动版本太低，低版本的 Presto JDBC 驱动对 PreparedStatement 的支持不完善，特别是对超长 SQL 的处理有 bug。 服务端 Presto 没有同步升级。原因很简单——影响太大，涉及的下游服务和业务太多，不敢动。 所以就出现了一个尴尬的局面：客户端驱动升级了（为了安全），服务端没升级（为了稳定），两边版本不一致，超长 SQL 直接 400。 解决方案 还原升级。 把客户端驱动退回到兼容当前服务端的版本。安全问题用其他方式规避（比如在应用层做参数化查询、输入校验等）。 这不是最优解，但在"安全"和"可用"之间，先保可用。 避坑建议 1. 灰度环境重点覆盖验证 stg 环境为什么没发现？因为测试用的 SQL 都是短的。灰度环境应该重点覆盖边界场景： 超长 SQL（1MB+） 特殊字符 高并发场景 2. 客户端和服务端版本要对齐 升级驱动前，先确认服务端版本兼容性。不要客户端升了、服务端没升，两边版本不一致是定时炸弹。 3. 安全整改要评估影响面 ...

引言 在开发者的潜意识里，LIMIT 关键字就是 SQL 查询的安全带。 我们通常认为，只要加了 LIMIT，无论表多大，数据库都只会吐出少量数据，内存就是安全的。 然而，最近的一次线上 OOM（内存溢出）事故狠狠地打破了这个认知。 一个看似人畜无害的 UNION ALL + LIMIT 组合，竟然避开了doris 的优化器的下推机制，引发了生产环境的连锁崩溃。 本文记录了这次在受限环境下，如何抽丝剥茧定位 Bug 的过程。 一、高峰期的“幽灵”崩溃 环境背景： 部署方式 Kubernetes 网关： Springboot + zuul 服务： Spring Boot + MyBatis db： Apache Doris 报错服务： 网关 java版本： jdk8, g1 权限： 无root权限,只能查看基本日志 网关pod报错关键日志 netflix.zuul.exception.ZuulException: Filter threw Exception postModifyResponseBodyFilter.run ... Caused by: java.lang.OutOfMemoryError: Java heap space 报错日志关键字: oom 二、 真相误判：GC 的烟雾弹 面对 OOM，作为 Java 开发者的第一直觉往往是：“是不是流量太大，垃圾回收（GC）跟不上了？” 查看存活期间的 JVM 监控，发现 Old Gen（老年代）增长迅速。当时的判断是：CMS 回收器产生内存碎片，导致大对象分配失败。 ...

debug调试问题是经常用到的， 在调试状态有时候需要复制list对象的某个属性值，一个个复制是不现实的 这个时候Idea调试状态的 Evaluate Expression 工具就派上大用场了 在Expression输入框，根据自己的需求，转换后，转换为json格式，然后右键复制即可

Spring-动态替换Bean 问题 假如spring-boot项目引用了第三方库， 里面有个类通过autowire引用了：testService， 如何修改testService里面的实现逻辑呢？ 通过动态替换testService为自定义的bean可以实现这个功能 实现原理 添加一个新的TestService2与原testService实现同样的接口 添加一个组件实现： BeanDefinitionRegistryPostProcessor 使用BeanDefinitionRegistry动态替换bean 代码示例 @Component public class MyBeanProcessor implements BeanDefinitionRegistryPostProcessor { @Override public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException { final String beanName = "testService"; if (registry.containsBeanDefinition(beanName)) { registry.removeBeanDefinition(beanName); GenericBeanDefinition beanDefinition = new GenericBeanDefinition(); beanDefinition.setBeanClass(TestService2.class); registry.registerBeanDefinition(beanName, beanDefinition); } } @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory factory) throws BeansException { } }