已引入spring-core仍报CollectionUtils.newLinkedHashMap的NoSuchMethodError原因

该错误属于典型的运行时类版本不匹配问题：编译期代码依赖的org.springframework.util.CollectionUtils类包含newLinkedHashMap方法，但运行时类加载器加载的该类不包含对应方法，即便pom中显式声明了5.3.0版本的spring-core依赖也会触发。

常见触发原因 #

• Tomcat容器级依赖冲突：Tomcat 8的%CATALINA_HOME%/lib目录下如果存在低版本spring-core包，会遵循双亲委派类加载机制，优先于应用WEB-INF/lib下的5.3.0版本spring-core加载。低于3.2版本的Spring Core中没有newLinkedHashMap方法，会直接触发报错。
• 传递依赖引入多版本Spring Core：即使pom中声明了Spring依赖统一版本，仍可能有第三方非Spring依赖默认携带低版本spring-core传递依赖，导致应用类路径下同时存在多个版本的spring-core包，类加载器随机加载到无对应方法的旧版本。
• 第三方Jar包重写冲突：部分二方包、三方包会重新打包Spring核心类，将org.springframework.util.CollectionUtils直接打入自身Jar中，该重写类如果没有对应方法，会优先于官方spring-core的类被加载。
• 打包异常：Maven打包过程中如果出现资源冲突、覆盖问题，可能导致最终打入War包的spring-core版本不是5.3.0，或者Jar包损坏无法读取对应方法。

排查方案 #

• 执行Maven命令mvn dependency:tree | grep spring-core 排查所有传递依赖，找到低版本spring-core的引入源，通过<exclusion>标签排除即可。
• 检查Tomcat的lib目录，删除所有Spring相关的Jar包，避免容器级依赖覆盖应用依赖。
• 解压打好的War包，检查WEB-INF/lib目录下的spring-core版本，确认只有5.3.0版本的对应Jar。
• 运行时添加调试代码，直接确认类加载来源：

System.out.println(org.springframework.util.CollectionUtils.class.getProtectionDomain().getCodeSource().getLocation());

内容的提问来源于stack exchange，提问作者Pratiksha Bhere