Можно ли использовать Runnable содержащие затворы

Question

Я использую libgdx для игры, которую я пишу, где у меня есть другой поток, который должен обновить графический поток. Я получал сбои, поскольку libgdx не был потокобезопасным (намеренно), и я разрешал другому потоку напрямую изменять переменную в графическом потоке.

libgdx docs предлагает что-то похожее на следующий код. Это в основном закрытие, содержащее входящую информацию, которая затем обрабатывается, когда графический поток попадает на нее.

Я изменил его, чтобы объявить runnable вне слушателя в надежде, что я смогу избежать сбора мусора, но мне приходит в голову, что я, возможно, создал условие гонки теперь, когда runnable может быть перезаписан до графическая нить, потребляющая предыдущую информацию?

До сих пор мне удалось избежать сбора мусора повсюду, и моя игра также использует привязки аудио с низкой задержкой в ​​Android, поэтому сбор мусора - это действительно мой враг.

Любые предложения?

private Runnable runnable; 
private SomeListener listener = new SomeListener() { 
    @Override 
    public void messageIn(final String source, final String s, final Object... l) { 
     runnable = new Runnable() { 
      @Override 
      public void run() { getWorkspace().messageIn(s,l); } 
     }; 
     Gdx.app.postRunnable(runnable); 
    } 

};

Answer 1

Я изменил его, чтобы объявить исполняемые за пределы слушателя в надежде, что я мог бы избежать сбора мусора, но это происходит со мной, что я, возможно, создал условие гонки, где сейчас работоспособные может быть перезаписан до к графической нити, потребляющей предыдущую информацию?

Да, это, безусловно, может случиться. Кроме того, вы не можете использовать ThreadLocal, потому что это будут разные потоки, обрабатывающие обратный вызов по сравнению с runnable.

Что вы можете сделать, это создать BlockingQueue классов Runnable. Как только метод запуска заканчивается, Runnable может поставить себя в конце BlockingQueue для повторного использования. Когда вызывался метод messageIn(...), он вызывал бы queue.poll() и только создавал новый, если в очереди не было ни одного. Это увеличило бы синхронизацию памяти, но уменьшило бы полосу пропускания GC. Это может не сильно выиграть.

Возможно, вы планируете использовать профилировщик памяти, чтобы убедиться, что именно здесь вы должны сосредоточиться на своем рефакторинге, чтобы попытаться снизить использование памяти.

Answer 2

Поскольку вы разрабатываете игру, я предлагаю вам отправить все сообщения в очередь, и вы будете потреблять тогда в игровом цикле по мере необходимости.