是，OracleCommand未释放会导致内存持续升高。因其持有未关闭的OracleDataReader或未释放的OCI句柄等非托管资源，.NET GC无法自动回收，引发典型内存泄漏。
OracleCommand未释放会导致内存持续升高吗
会，而且非常典型。不是gc没回收，而是对象根本没被标记为可回收——oraclecommand持有未关闭的oracledatareader或未释放的语句句柄时，底层odp.net会持续占用非托管内存（如oci句柄、绑定缓冲区），这部分不会被.net gc自动清理。
怎么确认是OracleCommand没释放而不是GC延迟
关键看内存增长是否与数据库调用频率强相关，且重启后归零但几小时内复现。此时别急着怀疑GC配置，先验证代码行为：
-
OracleCommand必须和OracleConnection在同一个using作用域里创建，否则Dispose()不保证触发命令资源释放 - 执行
ExecuteReader()后，OracleDataReader必须显式.Close()或包裹在using中；仅connection.Close()不等于reader.Close() - 若用了
CommandBehavior.CloseConnection，必须确保reader被完全消费完（如遍历到底）再离开作用域，否则连接不会真正归还池中 - EF Core 或 Dapper 场景下，避免在
foreach循环外保留DbDataReader引用——它背后就是OracleDataReader
用dotMemory或Visual Studio Diagnostic Tools快速定位
不用等OOM，直接抓一个内存快照比对：
- 筛选类型名含
OracleCommand或OracleDataReader的实例数，看是否随请求量线性增长 - 检查这些对象的
_statementHandle或_ociStmt字段是否非空（非托管句柄存在即未释放） - 查看引用链：如果某个
OracleCommand被静态集合、缓存字典或事件处理器长期持有，就是泄漏根因 - 特别注意异步场景：
await command.ExecuteReaderAsync()后若没await reader.ReadAsync()就返回，reader可能处于挂起状态，句柄不释放
连接字符串里Metadata Performance=Enabled能缓解吗
不能。这个参数只跳过首次DML时查all_cons_columns等系统表的开销，跟OracleCommand生命周期无关。它解决的是元数据发现慢的问题，不是内存泄漏。
真正要盯死的，是每个OracleCommand实例是否严格配对了using或Dispose()，尤其在异常分支里——catch块里吞掉异常却不释放命令，是最隐蔽也最常发生的内存爬升点。
