安装32位Java8后 配置正确仍触发Spark-Scala项目mvn install内存不足异常

• 你执行mvn --version 返回的信息完全正确，因为Maven的Windows启动脚本mvn.cmd 会优先读取JAVA_HOME 环境变量定位主进程运行的Java版本，这一步不会被系统安装的32位Java干扰。
• 触发内存异常的实际环节在Maven测试执行阶段：Spark-Scala项目的单元测试由Surefire插件负责运行，该插件默认会fork一个完全独立的测试JVM进程执行用例，不与Maven主进程共享运行环境。
• 关键的路径查找优先级差异：Surefire插件定位测试JVM时，如果POM文件没有显式配置fork用的Java绝对路径，会按照系统PATH环境变量的顺序查找第一个匹配的java.exe。
• Windows版32位Java8的安装程序，会自动将自身的bin目录路径插入到系统PATH的最前端，优先级高于你配置的64位Java路径。这就导致Surefire实际fork出来跑Spark测试用例的进程，实际调用的是32位版本的Java。
• 32位Java在Windows上运行时，受进程虚拟地址空间限制，通过系统API读取到的可用内存值仅为247.5MB（对应异常里的259522560字节），达不到Spark初始化时要求的最低450MB内存阈值（对应异常里的471859200字节），因此抛出IllegalArgumentException。
• 少数场景下32位Java安装会全局写入_JAVA_OPTIONS 低内存参数，但这类配置会直接影响Maven主进程的启动，不会只在Spark测试阶段触发内存校验异常，因此不是本次问题的核心诱因。
• 卸载32位Java后，系统PATH里的32位Java路径被自动移除，Surefire查找Java时会定位到正确的64位版本，内存检测逻辑恢复正常，因此构建可以顺利执行。

• 在POM的Surefire插件配置中，显式指定fork用的Java绝对路径，绕过系统PATH的路径查找逻辑。
• 调整系统PATH环境变量的顺序，把64位Java的bin路径调整到32位Java路径的前面。
• 修改Surefire插件配置，关闭测试阶段的fork模式，让测试用例直接运行在Maven主进程（也就是你配置正确的64位Java进程）中。

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