【问题标题】:Avoiding Concurrent Modification避免并发修改
【发布时间】:2015-03-09 08:09:05
【问题描述】:

假设我正在制作一个游戏,其中屏幕在帧速率限制内尽可能频繁地更新,但对象仅在游戏滴答时钟上更新。如何在不冒并发修改风险的情况下渲染复杂对象?例如,如果我需要渲染引擎访问有关类对象的详细信息以做出图形决策,而这些对象可能会同时被游戏引擎更改。

我想在渲染之前制作对象的深层副本会起作用,但是在复制过程中不会发生同样的问题吗?我假设在逐个复制数组列表时编辑它会导致问题。像这样的时候,我认为有一些我不知道的行业标准。

【问题讨论】:

    标签: java rendering standards deep-copy concurrentmodification


    【解决方案1】:

    这是一个复杂的问题,但我会尽量给你一些我在处理这个问题时发现的指针。首先是数组和列表的问题。我发现有用的是根据您用来保存对象的列表生成一个新列表。这样,您只需在创建新列表时小心编辑列表。完成后可以丢弃创建的列表。如果可以的话,还要避免从列表中删除项目或更改它们在列表中的位置。这使得引入并发问题变得容易得多。

    现在是渲染问题。假设您一次只有一个线程渲染。我发现创建一个保持更改并在每个渲染周期结束或开始时进行实际更改的对象很有用,这样您可以随时更改对象,但更改在下一个渲染周期之前不会生效。

    【讨论】:

    • 非常感谢。澄清一下,您是说我应该在每个渲染步骤之前复制实际列表吗?如果是这样,我怎样才能避免在复制过程中编辑该列表?
    • 这是一种方法。但是,如果可以的话,您应该避免移除/更改位置对象(在渲染期间)。如果您最后添加项目没有问题,您可以将项目添加到列表中。然后发生的事情是它要么包含在新列表中,要么下次包含。如果列表很小,在列表中保留一些不必要的对象通常没有问题。您还可以在存储在列表中的类中创建一个标志,以了解是否应将其包含在新列表中,而不是直接编辑列表。然后,您可以在渲染开始或结束时移除对象。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-11-04
    • 1970-01-01
    • 2013-08-15
    相关资源
    最近更新 更多