完成队列，不能很快释放

| 我有一个针对服务器上的Oracle DB运行的c＃3.5框架Windows应用程序。 应用程序的一种形式在顶部具有八个选项卡。每个选项卡的选项卡内容区域中是一个组合框。组合框在每个表单上显示相同的信息。当用户使用下拉或键盘箭头更改组合框值时，八个选项卡式区域将填充从Oracle中提取的数据。 根据现有程序的结构，每次更改组合框时，都会打开大约20个单独的DB连接。首先，调用大约8个命令将数据从不同选项卡保存到正确的表中。每个选项卡的内容都传递给数据库类，以保存该选项卡的数据。其次，基于组合框，进行了大约8个DB调用以从表中加载选项卡。 澄清一下，这就像在任何更改汽车型号的选项卡上选择一个组合框。每个选项卡都将是\“内部选项\” \“引擎选项\”等。 然后，进行了两个数据库调用以根据ID锁定高级记录，因此没有其他人可以同时编辑该特定记录。 总体而言，该过程非常可靠。保存/加载时间很快。我可以在两个不同的组合框值之间来回切换，几乎可以立即保存/加载数据。 然后出现问题 如果我足够快地来回旋转（几个用户也完成了此操作），则整个程序将挂起。没有崩溃，只是挂起。 在调试环境中重复此操作，我发现它总是停在同一行代码上（一个简单的记录集分配（例如CarModelInterior.Notes = Convert.ToString（myReader [6]）;） 然后我发现垃圾收集器（GC）线程在后台运行，但每次也都在同一位置停止。 输入RED-Gate内存/性能监视器的安装。 我发现，切换组合框值的速度越来越快，GC Finalizer队列填满的速度就越快。最终，似乎相同的SQL调用位于列表的顶部。 输入我的假设和猜测。 我的想法是打开的连接太多而没有足够快地完成连接，或者某个地方存在锁。 我可以说的是，整个程序中的所有DB调用（每个（每个））都使用\“ USING \”语句，因此所有处理都会自动完成。另外，ALL（就像是的，我检查了整个应用程序），所有的DB调用都在主线程上。因此，对每个组合框值更改进行的所有20个左右的DB调用是按顺序进行的。至少就可能的单线程问题而言，这消除了锁定的可能性。 我还剩下什么？在这一点上，我已经放弃了太多的谷歌搜索工作，并将其发布在这里。终结队列处理速度是否可能不够快？还有其他想法吗？