Windows图形捕获会话随机丢失问题求助（JNA+Direct3D实现）

安全阿岳

2026-6-13

问题原因分析

非线程安全Map的并发读写损坏：如果用的是HashMap这类非线程安全容器，捕获线程和其他业务线程同时对map做增删查操作时，会导致内部哈希表结构损坏，出现元素“莫名消失”的情况——这是并发场景下非线程安全集合的典型问题，哪怕没主动调用remove，结构损坏后也会出现元素找不到的情况。
弱/软引用导致的GC回收：如果map里存的是WeakReference<CaptureSession>这类弱引用对象，当CaptureSession没有其他强引用时，GC会自动回收这个引用，从map里看起来就是元素被移除了。
未捕获异常触发的隐式移除逻辑：虽然你说没主动写remove，但捕获线程如果抛出未处理的异常，可能触发了某个全局异常处理器或者try-catch块里的隐藏逻辑（比如错误清理时误删）；另外Windows API的回调函数如果出现异常，可能会导致JNA的线程处理逻辑间接影响map。
JNA回调线程的非预期操作：Windows图形API的回调（比如帧捕获回调）可能在系统线程池的线程里执行，如果回调里直接操作map，而这些线程的上下文没做同步，也可能导致map操作异常。

解决方案

替换为线程安全Map：把原来的HashMap换成ConcurrentHashMap，或者用Collections.synchronizedMap()包装原map——前者性能更好，适合高并发场景，后者是简单的同步包装。所有对map的读写操作都通过这个线程安全容器进行，避免并发损坏。
检查引用类型：如果用了弱/软引用存储CaptureSession，改成强引用；如果必须用弱引用，确保CaptureSession在整个生命周期内有其他强引用持有（比如在业务逻辑里保留一个list存session实例）。
排查隐式移除逻辑：
- 给所有map的remove操作加日志，包括自己写的和第三方库可能调用的（比如JNA的清理逻辑）；
- 给CaptureSession加finalize方法（或者用PhantomReference），打印回收日志，确认是不是GC导致的；
- 捕获线程里加全局try-catch，打印所有未处理异常，看是不是异常触发了清理逻辑。
同步JNA回调中的map操作：如果在Windows API的回调函数里需要访问map，一定要加同步锁（比如用synchronized块，或者用ConcurrentHashMap的原子操作），避免跨线程的非同步访问。
跟踪map的所有操作：临时给map做一个包装类，重写所有put/get/remove方法，每个方法都打印调用线程ID、操作内容和当前map大小，这样能定位到是哪个线程在什么时候移除了元素——这是排查这类问题最直接的办法。

举个简单的包装类例子：

public class TrackedMap<K, V> implements Map<K, V> {
    private final Map<K, V> delegate;

    public TrackedMap(Map<K, V> delegate) {
        this.delegate = delegate;
    }

    @Override
    public V put(K key, V value) {
        System.out.printf("[Thread %d] Put key: %s, current size: %d%n", 
            Thread.currentThread().getId(), key, delegate.size());
        return delegate.put(key, value);
    }

    @Override
    public V remove(Object key) {
        System.out.printf("[Thread %d] Remove key: %s, current size: %d%n", 
            Thread.currentThread().getId(), key, delegate.size());
        return delegate.remove(key);
    }

    // 其他map方法同理，都加上日志
}

用这个包装类替换原map，运行后看日志就能找到是谁在执行remove操作。

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