winamd64/openjdk

OpenJDK的预发布/非生产环境构建版本

88 收藏0 次下载activewinamd64镜像

注意： 这是 openjdk 镜像的 windows-amd64 架构构建的"每个架构"仓库 -- 更多信息，请参阅镜像文档中的 "除 amd64 之外的架构？" 和***镜像常见问题中的 "镜像的源代码在 Git 中已更改，现在该怎么办？"。

弃用通知

此镜像已正式弃用，建议所有用户尽快寻找并使用合适的替代方案。以下是其他***镜像替代方案的一些示例（按字母顺序排列，不表示任何有意或暗示的偏好）：

amazoncorretto
eclipse-temurin
ibm-semeru-runtimes
ibmjava
sapmachine

有关更多信息，请参见 docker-library/openjdk#505。

2022年7月之后，只有早期访问版本（源自 jdk.java.net）会继续接收更新，因为上述项目均未发布/支持这些版本。

快速参考

维护者：
Docker 社区
获取帮助的地方：
Docker 社区 Slack、Server Fault、Unix & Linux 或 Stack Overflow

支持的标签及相应的 `Dockerfile` 链接

（参见常见问题中的 "'Shared' 和 'Simple' 标签有什么区别？"）

Simple Tags

26-ea-19-jdk-windowsservercore-ltsc2025, 26-ea-19-windowsservercore-ltsc2025, 26-ea-jdk-windowsservercore-ltsc2025, 26-ea-windowsservercore-ltsc2025, 26-jdk-windowsservercore-ltsc2025, 26-windowsservercore-ltsc2025
26-ea-19-jdk-windowsservercore-ltsc2022, 26-ea-19-windowsservercore-ltsc2022, 26-ea-jdk-windowsservercore-ltsc2022, 26-ea-windowsservercore-ltsc2022, 26-jdk-windowsservercore-ltsc2022, 26-windowsservercore-ltsc2022
26-ea-19-jdk-nanoserver-ltsc2025, 26-ea-19-nanoserver-ltsc2025, 26-ea-jdk-nanoserver-ltsc2025, 26-ea-nanoserver-ltsc2025, 26-jdk-nanoserver-ltsc2025, 26-nanoserver-ltsc2025
26-ea-19-jdk-nanoserver-ltsc2022, 26-ea-19-nanoserver-ltsc2022, 26-ea-jdk-nanoserver-ltsc2022, 26-ea-nanoserver-ltsc2022, 26-jdk-nanoserver-ltsc2022, 26-nanoserver-ltsc2022

Shared Tags

26-ea-19-jdk, 26-ea-19, 26-ea-jdk, 26-ea, 26-jdk, 26:
- 26-ea-19-jdk-windowsservercore-ltsc2025
- 26-ea-19-jdk-windowsservercore-ltsc2022
26-ea-19-jdk-windowsservercore, 26-ea-19-windowsservercore, 26-ea-jdk-windowsservercore, 26-ea-windowsservercore, 26-jdk-windowsservercore, 26-windowsservercore:
- 26-ea-19-jdk-windowsservercore-ltsc2025
- 26-ea-19-jdk-windowsservercore-ltsc2022
26-ea-19-jdk-nanoserver, 26-ea-19-nanoserver, 26-ea-jdk-nanoserver, 26-ea-nanoserver, 26-jdk-nanoserver, 26-nanoserver:
- 26-ea-19-jdk-nanoserver-ltsc2025
- 26-ea-19-jdk-nanoserver-ltsc2022

快速参考（续）

提交问题的地方：
[***]
支持的架构： (更多信息)
amd64、arm64v8、windows-amd64
发布的镜像工件详情：
repo-info 仓库的 repos/openjdk/ 目录 (历史记录)
（镜像元数据、传输大小等）
镜像更新：
official-images 仓库的 library/openjdk 标签
official-images 仓库的 library/openjdk 文件 (历史记录)
本描述的来源：
docs 仓库的 openjdk/ 目录 (历史记录)

什么是 OpenJDK？

OpenJDK（Open Java Development Kit）是 Java 平台标准版（Java SE）的免费开源实现。自版本 7 起，OpenJDK 成为 Java SE 的***参考实现。

***.org/wiki/OpenJDK

Java 是 Oracle 和/或其关联公司的注册商标。

!logo

如何使用此镜像

在应用中启动 Java 实例

使用此镜像最直接的方式是将 Java 容器同时用作构建和运行时环境。在 Dockerfile 中，可以编写如下内容来编译和运行项目：

dockerfile
FROM winamd64/openjdk:11
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN javac Main.java
CMD ["java", "Main"]

然后可以构建并运行 Docker 镜像：

console
$ docker build -t my-java-app .
$ docker run -it --rm --name my-running-app my-java-app

在 Docker 容器内编译应用

有时可能不适合在容器内运行应用。要在 Docker 实例内编译（而非运行）应用，可以执行如下命令：

console
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp winamd64/openjdk:11 javac Main.java

这会将当前目录作为卷添加到容器，将工作目录设置为该卷，并运行 javac Main.java 命令，该命令会指示 Java 编译 Main.java 中的代码，并将 Java 类文件输出到 Main.class。

让 JVM 尊重 CPU 和 RAM 限制

JVM 在启动时会尝试检测可用的 CPU 核心数和 RAM，以相应调整其内部参数（如生成的垃圾回收器线程数）。当容器以有限的 CPU/RAM 运行时，JVM 用于探测的标准系统 API 将返回主机范围的值。这可能导致旧版本 JVM 出现过高的 CPU 使用率和内存分配错误。

在 Linux 容器中，OpenJDK 8 及更高版本可以正确检测容器限制的 CPU 核心数和可用 RAM。对于所有当前支持的 OpenJDK 版本，此功能默认启用。

在 Windows Server（非 Hyper-V）容器中，可用 CPU 核心数的限制不起作用（被主机计算服务忽略）。要手动设置限制，可以按如下方式启动 JVM：

console
$ start /b /wait /affinity 0x3 path/to/java.exe ...

在此示例中，CPU 亲和性十六进制掩码 0x3 会将 JVM 限制为 2 个 CPU 核心。

Windows Server 容器支持 RAM 限制，但 JVM 当前无法检测到它。为防止过度内存分配，必须指定 -XX:MaxRAM=... 选项，其值不得大于容器的 RAM 限制。

名称带点的环境变量

某些 shell（特别是 Alpine Linux 中包含的 BusyBox /bin/sh）不支持名称带点的环境变量（技术上不符合 POSIX 标准），因此会剥离它们而不是传递（如 Bash 所做的那样）。如果应用需要此类环境变量，可以直接使用 CMD ["java", ...]（不使用 shell），或者（安装并）显式使用 Bash 而非 /bin/sh。