Docker是封装适配器而非升级工具，通过隔离固化旧版Java项目（如JDK 6/7/8、Tomcat 6/7、Spring 3.x）的运行时环境，使其在新系统中原样运行；关键在于实测验证JDK精确版本、JVM参数、外部服务依赖及路径硬编码，并选用匹配的历史基础镜像（如tomcat:7.0.109-jre7）和兼容性优先的Dockerfile，避免alpine导致的glibc兼容问题。
旧版Java项目（如JDK 6/7/8、Spring 3.x、Tomcat 6/7）常因环境依赖陈旧、系统升级受限而难以直接迁移。Docker不是“升级工具”，而是“封装适配器”——它不改变代码，只隔离并固化运行时环境，让老项目在新系统上原样运行。
确认旧项目运行依赖
这是最关键的前置动作。不能只看pom.xml或build.xml，必须实测验证：
- 准确的JDK版本（例如：
java -version输出是否含1.7.0_80这类带更新号的精确版本） - 是否依赖特定JVM参数（如
-XX:PermSize、-Dfile.encoding=GBK） - 外部服务连接方式（如Oracle 10g JDBC驱动、WebLogic JNDI、自建RMI注册中心）
- 文件路径硬编码（如
/opt/app/config/）或Windows风格路径（C:\conf\）
选用匹配的基础镜像
避免“用新版镜像跑老程序”的常见陷阱。优先从Docker Hub官方OpenJDK仓库中选取历史标签：
- JDK 7u80 → 使用
openjdk:7u80-jdk（注意：该镜像仅存于旧版Docker Hub，需用docker pull直接拉取） - JDK 8u131 → 使用
openjdk:8u131-jdk-slim（比alpine更兼容老库） - 若项目打包为WAR且依赖Tomcat → 直接选用
tomcat:7.0.109-jre8或tomcat:8.5.94-jre8 - 慎用
alpine变体：glibc兼容性差，老项目调用JNI或本地库易崩溃
编写兼容性优先的Dockerfile
不追求最小镜像，而追求行为一致。示例（适配JDK 7 + WAR部署）：
# 使用已知稳定的旧版基础环境 FROM tomcat:7.0.109-jre7 <h1>复制WAR包（不重命名，保留原始上下文路径）</h1><p>COPY myapp.war /usr/local/tomcat/webapps/</p><h1>还原关键JVM参数（写入catalina.sh）</h1><p>RUN sed -i '/^JAVA_OPTS=/c\JAVA_OPTS="-Xms512m -Xmx1024m -XX:PermSize=256m -Dfile.encoding=GBK"' \ /usr/local/tomcat/bin/catalina.sh</p><h1>暴露默认端口</h1><p>EXPOSE 8080</p><h1>启动前检查日志目录权限（老应用常因权限失败静默退出）</h1><p>CMD ["sh", "-c", "chown -R tomcat:tomcat /usr/local/tomcat/logs && exec catalina.sh run"] </p>
运行时适配与验证要点
容器启动后不能只看docker ps，要模拟真实生产行为：
- 映射宿主机时间：加
--volumes-from或挂载/etc/localtime，避免老项目依赖系统时区出错 - 网络兼容：若项目使用
InetAddress.getLocalHost()获取IP，启动时加--network host或固定--add-host - 中文乱码：确保
docker run命令中包含-e LANG=C.UTF-8，并在Dockerfile中安装locales包 - 验证方式：curl访问健康接口 + 查看
docker logs -f中是否有SEVERE级错误 + 检查应用自身日志文件（挂载-v /host/logs:/usr/local/tomcat/logs）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
