用System.getProperty("user.dir")在AWS获取资源路径报NoSuchFileException，本地正常

• System.getProperty("user.dir")不存在AWS环境下的特殊运行逻辑，它的返回值始终是当前JVM进程启动时的工作目录，和云厂商环境没有绑定关系。你在AWS环境拿到的/usr/share/apache-tomcat-8.5.30，是因为Tomcat服务默认从自身安装根目录启动JVM，这和你本地IDE启动时默认把项目根目录设为工作目录的行为完全不同，直接导致了路径错位。
• 你怀疑的硬编码拼接src/main/resources的逻辑确实是故障核心：src/main/resources是Maven/Gradle构建体系下的源码目录结构，这个路径仅在本地源码运行、IDE启动的开发场景下存在。当项目打包成WAR部署到Tomcat时，构建工具会自动将resources目录下的所有文件输出到WAR包根路径，原本的src/main/resources目录结构不会被打入部署产物，自然会抛出目录不存在的异常。

• 彻底废弃通过user.dir拼接源码路径的写法，这套逻辑从设计层面就只适配本地开发场景，无法兼容生产部署的目录结构。
• 如果.jmx文件作为应用内置资源存放在classpath下，直接通过类加载器定位资源路径，不要手动拼接文件系统绝对路径：

  部署到Tomcat后，resources目录下的文件会被构建工具输出到应用的WEB-INF/classes路径下，通过类加载器可以自动定位到这个路径，不需要硬编码层级关系，也能适配本地、生产等不同部署环境的路径差异。

• 如果需要将.jmx文件存放在应用外部目录供运行时读取，可以在Tomcat启动配置中通过JVM参数传入资源目录的绝对路径，例如添加启动参数-Djmx.file.dir=/opt/app/jmx-templates，代码中直接读取该系统属性指定的路径，避免依赖默认工作目录。

注意：原代码中Files.walk打开的文件流未纳入自动资源管理，长期运行会引发文件句柄泄漏，修复路径问题时需要一并将流的初始化纳入try-with-resources块，确保流被正确关闭。

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