是，SDKMAN的核心能力就是同时管理多个Java版本，通过动态修改JAVA_HOME和PATH实现各终端会话独立使用不同JDK，并支持项目级自动切换、厂商版本搜索、手动安装及与IDE/CI协同。
SDKMAN能同时管理多个Java版本吗
能，而且这是它的核心能力。SDKMAN不是简单切换全局Java，而是通过export JAVA_HOME和export PATH动态调整环境变量，让不同终端会话可独立使用不同JDK。
常见错误是装完多个版本后执行java -version仍显示旧版本——本质是没运行sdk use java <version>或没在当前shell中生效。
- 每个shell会话需单独执行
sdk use java 17.0.2-tem才生效 -
sdk default java 21.0.1-tem设的是新打开终端的默认值，不影响已有终端 - 项目级配置可写
.sdkmanrc文件，内容为java=17.0.2-tem，进入目录自动切换
安装OpenJDK和GraalVM时版本号怎么查
别靠猜或浏览器翻页，直接用SDKMAN内置搜索：
sdk list java
输出里每行格式是vendor-version-id，比如temurin-17.0.2+8、graalvm-22.3.0-java17。注意三点：
立即学习“Java免费学习笔记（深入）”；
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
- 不同厂商命名规则不同：
temurin用语义化版本，graalvm带-java17后缀表示基线JDK - 带
+N（如+8）的是构建号，影响安全补丁级别，建议选最新小版本 - 某些版本标有
(EOL)代表已停止维护，避免在生产环境使用
为什么sdk install java 17.0.2-tem失败
最常见原因是网络问题导致下载中断，SDKMAN默认不重试且不提示详细错误。执行后若卡住或报Connection refused，优先检查：
- 是否被代理拦截：设置
export SDKMAN_CANDIDATES_API=https://api.sdkman.io/2再重试 - 是否DNS污染：尝试
ping api.sdkman.io，不通则换DNS（如1.1.1.1） - 磁盘空间不足：SDKMAN默认装在
~/.sdkman/candidates/java，确认df -h ~
若仍失败，手动下载包更可靠——从sdk list java输出中复制完整URL（如https://github.com/adoptium/temurin17-binaries/releases/download/jdk-17.0.2%2B8/OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8.tar.gz），用wget下好后运行：
sdk install java 17.0.2-tem /path/to/OpenJDK17U-jdk_x64_linux_hotspot_17.0.2_8.tar.gz
与系统自带Java或ASDF冲突怎么办
冲突根源是PATH顺序。SDKMAN把~/.sdkman/bin和~/.sdkman/candidates/java/current/bin加到PATH最前，但若你手动改过/etc/profile或~/.zshrc里的JAVA_HOME，就可能覆盖。
验证方法：执行which java和echo $JAVA_HOME，两者路径应一致且指向~/.sdkman/candidates/java/<version>。
- 卸载其他版本管理器前，先备份
~/.asdf或/usr/libexec/java_home相关配置 - Mac用户特别注意：
/usr/libexec/java_home -V列出的JDK不受SDKMAN控制，仅作参考 - CI/CD脚本中禁用交互式提示：加
export SDKMAN_AUTO_ANSWER=true
真正麻烦的是IDE（如IntelliJ）缓存了旧JDK路径，改完SDKMAN必须重启IDE并重新配置Project SDK，否则编译和运行时用的还是老版本。
