Java：过滤掉重复事件答案

【问题标题】：Java: Filtering out duplicate eventsJava：过滤掉重复事件
【发布时间】：2011-01-21 15:27:48
【问题描述】：

我想知道在接收回调/事件时，“常规”Java 应用程序是否常见以下情况。这些回调可能由用户输入触发，也可能由其他方式触发，因此它不仅与 UI 事件有关：

public void handleEvent( @NotNull final SomeEvent e ) {
    final boolean process;
    synchronized ( this ) {
        process = !e.equals(filter);
        filter = e;
    }
    if ( process ) {
        ...   
    }
}

基本上在一些复杂的方案下（非常复杂的 UI 涉及同一模型的多个视图，并且用户可以从不同的屏幕修改模型 [例如在复杂的 3D 程序中]）我有很多事件触发并且我已经注意到我可以使用上面的 sn-p 过滤掉重复的事件。如果一个事件已被处理并且下一个事件与上一个处理的事件完全相同（保存在filter 参考中），则事件/回调将被忽略。

它工作正常。我想知道过滤掉重复事件是否是一种常用技术？

【问题讨论】：

我以前从没听说过这个，但是我在涉及 UI 的 java 中做的编程不多

标签： java events filter callback

【解决方案1】：

看起来您可能有一个侦听器向同一个源注册了两次。这可能会导致它。或者您可能已经在多个实例中注册了一个侦听器。如果您发现奇怪之处，请寻找无限事件循环，不幸的是，由于 Swing 程序的组织方式，它很容易发生。你会想把这些听众分开。

我从未做过或遇到过这种事情。正如一些人指出的那样，某些控件会在调整选择时触发事件，但是有一些方法可以过滤掉这些东西。

synchronized( this ) 块也是可疑的，因为您总是会在 Swing 线程上被回调。如果你的程序不是这样，那么你就违反了 Swing 的线程规则，这可以解释问题。底线是您不需要同步块，因为 Swing 是单线程的。

（我假设这是 Swing 和其他一些海报一样，但仅从您的代码来看，它是模棱两可的）。

【讨论】：

【解决方案2】：

并非总是如此，但这通常表明事件级联链的某些元素没有正确检测到它们不需要发送事件。经典的例子是一个 bean setter，即使值没有改变，它也会生成一个 PropertyChangeEvent。

虽然您所做的将过滤掉这些事件，但它并没有解决可能是根本性的潜在问题。

问题是这些“错误”可以结合起来形成无限循环。扩展上面的 bean 示例，假设您有一个基于该 bean 字段重置其可编辑值的 UI……并且重置 UI 值也将调用 bean setter，因为那里也没有进行适当的重复检查。第一次编辑值会出现死循环。

这些示例在发生时是显而易见的，但随着通知层次结构变得越来越复杂，跟踪这些事情变得更加困难，并且它们可能在更间歇的时间发生。

一个好的经验法则是使每个事件生成组件尽可能保守。如果（呵呵）您收到来自您无法控制的组件的通知，并且还将转发您自己的事件，那么像您设置的过滤器可能是防止可能更大的传播的唯一选择问题不仅仅是性能。

【讨论】：

【解决方案3】：

我能想到的唯一事情是根据选择是否仍在更改（即用户仍在单击并拖动鼠标）或事件是否代表“最终”选择事件来处理ListSelectionEvent；例如

public class MyListSelectionListener implements ListSelectionListener {
  public void valueChanged(ListSelectionEvent evt) {
    // Finished selecting
    if (!evt.getValueIsAdjusting()) {
      JOptionPane.showMessageDialog("Selection Complete!");
    }
  }
}

【讨论】：