本文详解为何直接用多线程并发调用 graphics2d 绘图会导致图像错乱，并提供两种可靠解决方案：细粒度同步与推荐的“计算/绘图分离”架构。
本文详解为何直接用多线程并发调用 graphics2d 绘图会导致图像错乱，并提供两种可靠解决方案：细粒度同步与推荐的“计算/绘图分离”架构。
在 Java 桌面 GIS 应用（如基于 JMapViewer 或自定义地图渲染器）中，使用多线程加速 SRTM3 高程瓦片（1201×1201 像素）的可视化渲染是常见需求。然而，如问题所示：单线程下渲染正常，一旦启用 12 线程并行调用 Graphics2D 的 setColor() 和 draw()，输出图像便出现严重颜色错位、像素覆盖或空白区域——这并非数据错误，而是典型的共享 GUI 资源并发访问问题。
根本原因分析
Graphics2D（及其子类如 SunGraphics2D）不是线程安全的。其内部状态（如当前颜色、笔刷、变换矩阵、抗锯齿设置等）由多个方法共享且无内置同步机制。当多个线程同时调用 g.setColor(c) 和 g.draw(shape) 时，执行顺序不可预测：
Thread-1: g.setColor(RED) → 状态：color = RED Thread-2: g.setColor(BLUE) → 状态：color = BLUE （覆盖！） Thread-1: g.draw(rect) → 实际以 BLUE 绘制！ Thread-2: g.draw(rect) → 以 BLUE 绘制
此外，draw(new Rectangle(point)) 是一个复合操作（计算轮廓+填充/描边），若中间被其他线程中断，还可能引发 NullPointerException 或坐标偏移。
方案一：粗粒度同步（仅作教学参考，不推荐生产）
可通过共享锁对象对绘图关键段加锁，强制串行化：
立即学习“Java免费学习笔记（深入）”；
// 在类成员中声明（所有线程共享同一实例）
private static final Object GRAPHICS_LOCK = new Object();
// 在 run() 方法内替换绘图部分：
Point point = new Point((int) ptHeight.getX(), (int) ptHeight.getY());
java.awt.Color color = new java.awt.Color(
(int) (red * 255),
(int) (green * 255),
(int) (blue * 255),
255
);
synchronized (GRAPHICS_LOCK) {
g.setColor(color);
g.fillOval(point.x, point.y, 1, 1); // 推荐 fillOval 替代 draw(Rectangle) 提升性能
}⚠️ 注意：此方案虽能避免错色，但因锁竞争严重，12 线程实际退化为近似单线程，吞吐量不升反降，且未解决 Graphics2D 其他潜在状态冲突（如 clip、transform）。
方案二：计算与绘图分离（强烈推荐 ✅）
真正发挥多核优势的正确范式：多线程仅负责高开销计算（坐标转换、高程映射、颜色查表），结果写入线程安全的中间缓冲区；最终由 Swing 事件线程（EDT）统一绘图。
步骤实现：
-
定义线程安全的像素缓冲区
使用 int[] 存储 ARGB 像素（比 BufferedImage.setRGB() 更高效）：// 主线程创建 int[] pixelBuffer = new int[size * size]; // 按行优先存储：index = y * size + x
-
修改线程逻辑（纯计算，无 GUI 调用）
SrtmV2Thread.run() 中移除所有 g.xxx 调用，仅计算并写入 pixelBuffer：@Override public void run() { // ... 坐标转换、height 获取、percent 计算、colorHeight 生成（同前）... int argb = (0xFF << 24) | // Alpha ((int)(red * 255) << 16) | ((int)(green * 255) << 8) | (int)(blue * 255); // 关键：将 (x,y) 映射到 pixelBuffer 索引（注意 y 坐标需翻转以匹配 BufferedImage 原点） int screenX = (int) ptHeight.getX(); int screenY = (int) ptHeight.getY(); if (screenX >= 0 && screenX < size && screenY >= 0 && screenY < size) { int index = screenY * size + screenX; // 使用 volatile 数组或 AtomicIntegerArray？此处普通数组即可，因无竞态写入同一位置 pixelBuffer[index] = argb; } } -
主线程完成绘制
join() 后，在 EDT 中一次性渲染：// 所有线程 join 完毕后 BufferedImage tileImage = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB); tileImage.setRGB(0, 0, size, size, pixelBuffer, 0, size); // 在 paint() 中（确保在 EDT） g.drawImage(tileImage, 0, 0, null);
性能与健壮性增强建议
- 避免重复对象创建：将 GeoPosition、Point2D 等对象复用，或改用原始 double 数组传递坐标。
- 预分配颜色查找表（LUT）：若 min/max 固定，预先计算 int[256] 的 ARGB 数组，用 percent 直接索引，替代每次 genColor()。
- 使用 ForkJoinPool 替代裸线程：更高效管理线程生命周期，尤其适合递归分治型任务（如四叉树分块）。
- 校验坐标边界：ptHeight.getX()/getY() 可能为 NaN 或超出画布，务必做 if (Double.isFinite(x) && x >= 0) 判断。
通过计算与绘图职责分离，您不仅能彻底规避 Graphics2D 线程安全陷阱，还能获得接近线性的多核加速比——这才是高性能地理可视化开发的基石实践。
