Java 垃圾收集和图形处理方法答案

【问题标题】：Java Garbage Collection and Graphics dispose methodJava 垃圾收集和图形处理方法
【发布时间】：2012-12-31 02:35:54
【问题描述】：

我正在创建一个游戏（蛇克隆）作为一种爱好。我正在查看 Java API 中 Graphics 类的 dispose 方法。当我注释掉 dispose 方法时，无论有没有它，我的动画都可以正常工作。在 Java API 中， dispose 方法执行此操作 - 释放图形上下文正在使用的系统资源。 Java 垃圾回收不是像 dispose 那样管理程序的内存吗？我应该保留 dispose 方法吗？

API 在解释同步方法方面没有多大帮助。但是从我在其他论坛上看到的内容来看，ToolKit 类中的同步方法是为了确保绘图操作（如我想的 paintComponent 方法）刷新到显卡。那么图形卡的工作是清理程序先前图形上下文的任何残留物吗？

代码如下：

 public void paintComponent(Graphics g) {
            super.paintComponent(g);
            Toolkit.getDefaultToolkit().sync();
            g.dispose();

     }

【问题讨论】：

Javadoc 说：When a Java program runs, a large number of Graphics objects can be created within a short time frame. Although the finalization process of the garbage collector also disposes of the same system resources, it is preferable to manually free the associated resources by calling this method rather than to rely on a finalization process which may not run to completion for a long period of time.
永远不要依赖垃圾收集器来获取系统/非托管资源。您的 GC 可能会在几分钟内无法启动，而您的图形堆栈可能会耗尽，结果您将在拥有大量可用内存的同时停止查看图形。这发生在 .NET 中的 Java 中并不重要，因为 GUI 对象池受到限制，即即使您有 8 Gb 内存，也不能指望分配 1,000,000 个画笔。您拥有的内存越多 - GC 的攻击性越小，这就是问题所在。我在 .NET 中看到过许多应用程序绘制“红十字”而不是按钮和图像，然后在 5 分钟内恢复活力
图形堆栈位于操作系统中 - 这是合乎逻辑的事情，例如在 Windows 上的 gdi.dll 中。如果设备驱动程序支持某些硬件加速，那么画笔和笔之类的东西可能会被流水线化到 PCI 卡中。但是 GDI 是具有内部固定大小数组的瓶颈。例如，在 Android 上，2d 绘图是使用 SKIA 库制作的，每个画笔/笔都需要 ram
@Nicholas: docs.oracle.com/javase/7/docs/api/java/awt/…
图形堆栈 = 与“图形组件”一样，它是 2d 图元（至少）和窗口管理功能（管理区域中位图显示的功能）的渲染机制。这就是我所说的图形堆栈。不要与用于执行代码的堆栈段混淆，堆栈段是 CPU 专用寄存器（用于相对寻址和引用临时值的指针寄存器）

标签： java graphics sync dispose toolkit

【解决方案1】：

说到Graphics，有一个简单的原则。

如果您明确创建它（例如BuffereImage.createGraphics()），则将其丢弃。

paintComponent(Graphics g) 中的 OTOH 实例 g 由工具包提供，并在需要时/如果需要时处理。在您自己的代码中这样做会导致“不可预测”的渲染。

【讨论】：

我是从 java 文档中读到的——为了提高效率，程序员应该在使用完 Graphics 对象后调用 dispose，前提是它是直接从组件或另一个 Graphics 对象创建的。实际上我应该自己处理它，因为 Graphics 对象是创建图形上下文 g 的对象。我牢记原则。感谢知识，安德鲁！
也在这里讨论过：coderanch.com/t/540134/Performance/java/Graphics-dispose，同样的答案。