处理长时间运行的 EDT 任务（fi TreeModel 搜索）

Question

触发器是最近重新检测到的 SwingX 问题：支持深度 - 即位于折叠节点下与仅可见节点相反，这是当前的行为 - 节点搜索。

“Nichts leichter als das”以及我当前对 SwingWorker 的所有了解：在后台线程中遍历 TreeModel 并在进程中更新 ui，如下面的粗略代码片段所示。 Fest 的 EDT 检查器很高兴，但它只检查重绘（这在 EDT 上很好地发生）

只是......严格来说，该后台线程必须是 EDT，因为它正在访问（通过读取）模型。那么，问题是：

• 如何正确地实现搜索线程？
• 或者我们是否可以忍受这种风险（当然，有大量记录）

特殊情况解决方案的一种可能性是使用第二个（克隆或“相同”制造的）模型进行搜索，然后在“真实”中找到相应的匹配项“ 模型。这与一般搜索支持的配合不太好，因为它无法了解任何特定模型的任何信息，即使需要也无法创建克隆。另外，它必须应用所有视图排序/过滤（将来）...

// a crude worker (match hard-coded and directly coupled to the ui)
public static class SearchWorker extends SwingWorker<Void, File> {

    private Enumeration enumer;
    private JXList list;
    private JXTree tree;

    public SearchWorker(Enumeration enumer, JXList list, JXTree tree) {
        this.enumer = enumer;
        this.list = list;
        this.tree = tree;
    }

    @Override
    protected Void doInBackground() throws Exception {
        int count = 0;
        while (enumer.hasMoreElements()) {
            count++;
            File file = (File) enumer.nextElement();
            if (match(file)) {
                publish(file);
            }
            if (count > 100){
                count = 0;
                Thread.sleep(50);
            }    
        }
        return null;
    }


    @Override
    protected void process(List<File> chunks) {
        for (File file : chunks) {
            ((DefaultListModel) list.getModel()).addElement(file);
            TreePath path = createPathToRoot(file);
            tree.addSelectionPath(path);
            tree.scrollPathToVisible(path);
        }
    }

    private TreePath createPathToRoot(File file) {
        boolean result = false;
        List<File> path = new LinkedList<File>();
        while(!result && file != null) {
            result = file.equals(tree.getModel().getRoot());
            path.add(0, file);
            file = file.getParentFile();
        }
        return new TreePath(path.toArray());
    }

    private boolean match(File file) {
        return file.getName().startsWith("c");
    }

}

// its usage in terms of SwingX test support
public void interactiveDeepSearch() {
    final FileSystemModel files = new FileSystemModel(new File("."));
    final JXTree tree = new JXTree(files);
    tree.setCellRenderer(new DefaultTreeRenderer(IconValues.FILE_ICON, StringValues.FILE_NAME));
    final JXList list = new JXList(new DefaultListModel());
    list.setCellRenderer(new DefaultListRenderer(StringValues.FILE_NAME));
    list.setVisibleRowCount(20);
    JXFrame frame = wrapWithScrollingInFrame(tree, "search files");
    frame.add(new JScrollPane(list), BorderLayout.SOUTH);
    Action traverse = new AbstractAction("worker") {

        @Override
        public void actionPerformed(ActionEvent e) {
            setEnabled(false);
            Enumeration fileEnum = new PreorderModelEnumeration(files);
            SwingWorker worker = new SearchWorker(fileEnum, list, tree);
            PropertyChangeListener l = new PropertyChangeListener() {

                @Override
                public void propertyChange(PropertyChangeEvent evt) {
                    if (evt.getNewValue() == SwingWorker.StateValue.DONE) {
                        //T.imeOut("search end ");
                        setEnabled(true);
                        ((SwingWorker) evt.getSource()).removePropertyChangeListener(this);
                    }
                }
            };
            worker.addPropertyChangeListener(l);
            // T.imeOn("starting search ... ");
            worker.execute();
        }

    };
    addAction(frame, traverse);
    show(frame)
 } 

仅供参考：交叉发布到 OTN 的 Swing 论坛 和 SwingLabs论坛 - 将尝试在最后发布所有输入的摘要（如果有的话:-）

附录

在一天结束时，事实证明我问了错误的问题（或者错误上下文中的正确问题；-）：“问题”是由假设的解决方案引起的，真正要解决的任务是支持分层搜索算法（目前 AbstractSearchable 严重偏向于线性搜索）。

一旦这个问题得到解决，下一个问题可能是框架可以在多大程度上支持具体的分层搜索。考虑到 TreeModel 的自定义实现多种多样，这很可能只适用于最简单的实现。

这里和其他论坛的讨论中出现了一些想法。在具体的上下文中，首先测量遍历是否缓慢：大多数内存模型的遍历速度都快如闪电，除了使用基本支持之外不需要执行任何操作。

仅当遍历是瓶颈时（如 SwingX 的 FileSystemModel 实现中的 fi），才需要额外的工作：

• 在真正不可变且不可修改的 TreeModel 中，我们可能会在 SwingWorker 的后台线程中进行只读访问，但
• 在惰性中违反了不可修改的前提条件加载/删除场景
• 可能有一个支持模型的自然自定义数据结构，它实际上与实际模型“分离”，允许同步到该支持模型（在这两种情况下）遍历和视图模型）
• 将实际搜索传递回数据库
• ，在给定的 TreeModel 之上使用包装器，保证访问 EDT
• “假”后台搜索上的底层模型：实际上是在 EDT 上足够小的块中执行此操作（ fi 在计时器中），以便用户不会注意到任何延迟

无论慢速搜索的技术选项是什么，都需要解决相同的可用性问题：如何向最终用户呈现延迟？这是一个完全不同的故事，可能更依赖于上下文/需求:-)

Answer 1

SwingWorker 和 TreeModel 都应该同步对通用的底层 DataModel 的访问。使共享数据量（有效地）不可变可以最大限度地减少开销。由于这高度依赖于应用程序，因此我不确定该视图可以为搜索不可见节点提供多少支持。