前不久為用戶(hù)做了一個(gè)小工具,把數(shù)據(jù)中心的數(shù)據(jù)發(fā)布到其它相應(yīng)的數(shù)據(jù)庫(kù).到用戶(hù)的測(cè)試機(jī)上一跑,
10分鐘左右,內(nèi)存用光(1.5G)
,跟蹤看了一下
IBATISN.NET 1.6.1
的源碼,哈哈。。。找著根了
一、根位置 MappedStatement.cs
ibaits的數(shù)據(jù)真實(shí)操作都交給了這個(gè)類(lèi)。其中用一大堆與select相關(guān)操作的方法以及insert update delete相關(guān)方法,內(nèi)存泄漏就在這些方法上。簡(jiǎn)單看一下ExecuteInsert(insert)方法的代碼:
二、原因 IDispose 接口得顯示調(diào)用
using并不能釋放這些非托管資源
三、解決方法:看上面代碼
四、總結(jié)
以前用ibaits怎么就沒(méi)有發(fā)現(xiàn)在呢?
我想這與項(xiàng)目的實(shí)際應(yīng)用場(chǎng)景有關(guān),問(wèn)題一直都存在,只是沒(méi)有顯現(xiàn)吧了。
大多數(shù)據(jù)時(shí)候,用戶(hù)的輸入?yún)?shù)只有幾個(gè),相對(duì)較少,而且調(diào)用頻度應(yīng)該不高。
而這個(gè)應(yīng)用場(chǎng)景走的卻是另一個(gè)極端:
調(diào)用頻度極高:
數(shù)據(jù)中心實(shí)時(shí)采集4家公司的數(shù)據(jù),且數(shù)據(jù)更新高峰在開(kāi)收盤(pán)前后,中午休市最為集中,每天的數(shù)據(jù)更新在3000K左右,這些數(shù)據(jù)要及時(shí)發(fā)布到5個(gè)數(shù)據(jù)庫(kù)中
參數(shù)超多:
近200張表中有50多張賬務(wù)相關(guān)的表字段個(gè)數(shù)在100到230之間
這些字段最終是要轉(zhuǎn)換成 INSERT 與 UPDATE 語(yǔ)句中的參數(shù),
怪不得程序顯示超多OarcleParamter 對(duì)象無(wú)法回收,它不多才怪。。。
不過(guò)還好,加了上面的代碼后,程序內(nèi)存近期還沒(méi)超過(guò)150M,多在100M左右
如果你也有用IBAITS.NET,你可要小心了。。
這個(gè)問(wèn)題其實(shí)是由 IDispose 接口引起的, 不知道JAVA是什么樣子,源碼還沒(méi)仔細(xì)看
JAVA版本的3.0出來(lái)時(shí)間也不短了,易用性比 IBATIS.NET 1.6.1 要強(qiáng)太多了。
不知道 .NET 版本的更新什么時(shí)候出。。。
一、根位置 MappedStatement.cs
ibaits的數(shù)據(jù)真實(shí)操作都交給了這個(gè)類(lèi)。其中用一大堆與select相關(guān)操作的方法以及insert update delete相關(guān)方法,內(nèi)存泄漏就在這些方法上。簡(jiǎn)單看一下ExecuteInsert(insert)方法的代碼:
// 初始化 command 的參數(shù) _preparedCommand.Create(request, session, this.Statement, parameterObject); // 用 using 處理 command using (IDbCommand command = request.IDbCommand) { try { if (_statement is Insert) { generatedKey = command.ExecuteNonQuery(); } // Retrieve output parameter if the result class is specified else if (_statement is Procedure && (_statement.ResultClass != null) && _sqlMap.TypeHandlerFactory.IsSimpleType(_statement.ResultClass)) { ......// 省 } if (selectKeyStatement != null && selectKeyStatement.isAfter) { IMappedStatement mappedStatement = _sqlMap.GetMappedStatement(selectKeyStatement.Id); generatedKey = mappedStatement.ExecuteQueryForObject(session, parameterObject); ObjectProbe.SetMemberValue(parameterObject, selectKeyStatement.PropertyName, generatedKey, request.DataExchangeFactory.ObjectFactory, request.DataExchangeFactory.AccessorFactory); } //ExecutePostSelect(request); RetrieveOutputParameters(request, session, command, parameterObject); } // 下面這個(gè) finally 段是我加上去的,我不確定 command 的 dispose是否會(huì)調(diào)用相關(guān)Paramters中對(duì)象相應(yīng)的 dispose 方法,所以就用了下面這個(gè),因?yàn)槌绦蛑酗@示大量IDataParamter 對(duì)象無(wú)法回收 finally { if (command.Parameters.Count > 0){ MethodInfo mi = command.Parameters[0].GetType().GetMethod("Dispose", BindingFlags.Instance | BindingFlags.Public); if (mi != null) for (int i = 0; i < command.Parameters.Count; i++) mi.Invoke(command.Parameters[i], null); } command.Dispose(); } }
二、原因 IDispose 接口得顯示調(diào)用
using并不能釋放這些非托管資源
三、解決方法:看上面代碼
四、總結(jié)
以前用ibaits怎么就沒(méi)有發(fā)現(xiàn)在呢?
我想這與項(xiàng)目的實(shí)際應(yīng)用場(chǎng)景有關(guān),問(wèn)題一直都存在,只是沒(méi)有顯現(xiàn)吧了。
大多數(shù)據(jù)時(shí)候,用戶(hù)的輸入?yún)?shù)只有幾個(gè),相對(duì)較少,而且調(diào)用頻度應(yīng)該不高。
而這個(gè)應(yīng)用場(chǎng)景走的卻是另一個(gè)極端:
調(diào)用頻度極高:
數(shù)據(jù)中心實(shí)時(shí)采集4家公司的數(shù)據(jù),且數(shù)據(jù)更新高峰在開(kāi)收盤(pán)前后,中午休市最為集中,每天的數(shù)據(jù)更新在3000K左右,這些數(shù)據(jù)要及時(shí)發(fā)布到5個(gè)數(shù)據(jù)庫(kù)中
參數(shù)超多:
近200張表中有50多張賬務(wù)相關(guān)的表字段個(gè)數(shù)在100到230之間
這些字段最終是要轉(zhuǎn)換成 INSERT 與 UPDATE 語(yǔ)句中的參數(shù),

不過(guò)還好,加了上面的代碼后,程序內(nèi)存近期還沒(méi)超過(guò)150M,多在100M左右
如果你也有用IBAITS.NET,你可要小心了。。
這個(gè)問(wèn)題其實(shí)是由 IDispose 接口引起的, 不知道JAVA是什么樣子,源碼還沒(méi)仔細(xì)看
JAVA版本的3.0出來(lái)時(shí)間也不短了,易用性比 IBATIS.NET 1.6.1 要強(qiáng)太多了。
不知道 .NET 版本的更新什么時(shí)候出。。。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫(xiě)作最大的動(dòng)力,如果您喜歡我的文章,感覺(jué)我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
