Hibernate EntityManagerFactory连接Cloud SQL报NoSuchMethodError问题

抛出的com.google.common.util.concurrent.RateLimiter.acquire(I)D属于典型的依赖版本冲突问题，和JPA逻辑、数据库配置本身无关。
Cloud SQL MySQL Socket Factory 依赖高版本Guava库，其调用的RateLimiter.acquire(int)方法需要返回double类型的方法签名；而旧版MVC项目、甚至Web容器本身经常会自带低版本Guava，低版本中该方法的返回值为void，运行时加载到旧版本Guava的类时，就会抛出NoSuchMethodError。

• 确认项目实际生效的Guava版本
  Maven项目执行命令mvn dependency:tree -Dincludes=com.google.guava:guava，Gradle项目执行./gradlew dependencies | grep guava，梳理所有引入Guava的依赖路径，确认最终打包进产物的Guava版本号。
• 检查容器类加载路径
  如果应用部署在Tomcat等外部Web容器中，直接查看容器lib目录下是否存在Guava jar包。容器级类加载优先级高于Web应用内的依赖，会优先加载容器目录下的旧版本包，哪怕应用内已经引入了正确版本也会被覆盖。
• 核对版本匹配关系
  主流版本的Cloud SQL MySQL Socket Factory要求Guava版本不低于30.0-jre，低于该版本的Guava均不存在匹配的方法签名。

• 强制锁定Guava版本
  在项目依赖中直接引入符合要求的Guava版本，通过依赖管理规则强制所有路径使用该版本。
  Maven项目在pom.xml中添加如下依赖，并在dependencyManagement节点锁定版本：

  <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>32.1.3-jre</version>
  </dependency>
  

  Gradle项目在build.gradle中添加全局版本强制规则：

  configurations.all {
      resolutionStrategy.force 'com.google.guava:guava:32.1.3-jre'
  }
  

• 排除传递依赖引入的低版本Guava
  根据依赖树的输出，在所有引入低版本Guava的第三方依赖中添加排除规则，避免旧版本被传递引入：

  <exclusion>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
  </exclusion>
  

• 清理容器内的冲突依赖
  如果是外部容器部署场景，直接将容器lib目录下的旧版Guava包替换为30.0-jre以上版本，或删除容器lib下的Guava包，让应用加载自身WAR包内的正确版本。

• 当前代码中JDBC驱动类配置为com.mysql.jdbc.Driver，这是MySQL Connector/J 5.x版本的驱动类，如果后续升级MySQL驱动到8.x版本，需要将驱动类修改为com.mysql.cj.jdbc.Driver，避免出现驱动类找不到的错误。
• JDBC URL中不需要重复配置user、password参数，代码已经通过javax.persistence.jdbc.user和javax.persistence.jdbc.password单独传入数据库凭证，URL中硬编码这两个参数反而可能引发参数覆盖问题，建议直接删除URL中对应的参数段。

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