Swing图书管理程序JTable异常新增行及invokeLater调用问题求助

嘿，这是Swing开发里很典型的线程调度与状态同步问题，我来帮你理清楚根源并给出可行的解决办法：

你遇到的核心矛盾在于：当你在列表选择监听器里切换到BoundState时，SwingUtilities.invokeLater会把后续逻辑放到EDT（事件调度线程）的任务队列末尾。等监听器的代码完全执行完毕（此时状态已经变成BOUND），队列里的任务才会启动，这就导致原本预期在UNBOUND状态下执行的逻辑，错误触发了saveChanges()，把空白字段存成了新图书。而用invokeAndWait导致程序冻结，是因为UI监听器本身就在EDT线程里，调用invokeAndWait会让EDT线程阻塞等待自己完成任务，直接造成死锁。

下面是几个针对性的解决思路：

1. 保存状态快照，隔离后续变化的影响 #

在BoundState的构造函数里，先把当前的状态（也就是构造时的UNBOUND）保存到一个局部变量里，后续的逻辑判断用这个快照，而不是依赖可能被修改的全局状态。这样不管后续状态怎么变，invokeLater里的逻辑都会基于创建时的状态执行：

public class BoundState {
    public BoundState(StatesManager statesManager) {
        // 保存构造瞬间的状态快照
        final String initialState = statesManager.getCurrentState();
        SwingUtilities.invokeLater(() -> {
            if ("UNBOUND".equals(initialState)) {
                // 执行原本的逻辑，不受后续状态切换影响
            } else {
                // 状态已变化，跳过saveChanges操作
            }
        });
    }
}

这个方法最直接，不需要改变线程调用方式，只是通过快照避免了状态判断的时序问题。

2. 把状态切换和后续逻辑放到同一个EDT任务里 #

如果saveChanges()的触发逻辑必须依赖状态切换后的结果，那可以把状态切换的操作也放到invokeLater中，确保状态变化和后续逻辑在同一个EDT任务里执行，彻底避免顺序问题：

// 在UnboundState的selectBook方法里
public void selectBook(Book book) {
    SwingUtilities.invokeLater(() -> {
        statesManager.setBound(book);
        // 这里直接执行原本放在BoundState构造里的逻辑
        // 此时状态已经稳定为BOUND，判断逻辑完全准确
    });
}

这样状态切换和后续处理是原子性的EDT任务，不会出现因为调度顺序导致的状态不一致。

3. 分离构造与初始化逻辑，避免构造函数里的异步操作 #

把BoundState构造里的invokeLater逻辑移到一个单独的初始化方法中，等状态切换完全完成后再手动调用这个方法：

public class BoundState {
    private final StatesManager statesManager;

    public BoundState(StatesManager statesManager) {
        this.statesManager = statesManager;
        // 构造函数只做属性初始化，不执行异步逻辑
    }

    public void init() {
        SwingUtilities.invokeLater(() -> {
            if ("BOUND".equals(statesManager.getCurrentState())) {
                // 此时状态已经稳定，判断准确
                // 执行对应逻辑，不会误触发saveChanges
            }
        });
    }
}

// 在selectBook方法里
public void selectBook(Book book) {
    BoundState newState = new BoundState(statesManager);
    statesManager.setBound(book);
    newState.init();
}

这种方式把对象构造和UI逻辑初始化分离，让状态切换完全完成后再启动后续的EDT任务，从根源上避免了状态不一致的问题。

关于invokeAndWait冻结的补充 #

invokeAndWait会阻塞当前线程，直到EDT执行完提交的任务。而Swing的所有UI事件监听器（包括你的列表选择监听器）默认都是在EDT线程里执行的，这时候调用invokeAndWait会导致EDT线程等待自己完成任务，直接造成死锁。所以除非你在非EDT线程中处理逻辑，否则绝对不要用invokeAndWait来处理Swing UI相关的操作。

内容的提问来源于stack exchange，提问作者lolveley