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