8,735
社区成员
发帖
与我相关
我的任务
分享silverlight中MemoryStream内存释放问题？
using (MemoryStream ms = new MemoryStream())
{
using (StreamWriter writer = new StreamWriter(ms))
{
int count = 1024 * 1024 * 40;
char[] str = new char[count];
while (count-- > 0)
str[count] = '*';
writer.Write(str);
writer.Flush();
}
}
今天测试向MemoryStream中写入大数据，结果发现在silverlight中内存不会被释放，达200多MB，但在asp.net中可以。why？
...全文
请发表友善的回复…
发表回复
sundayX 2012-06-20
- 打赏
- 举报
这东西越来越不讨人喜欢了，呵呵。
无奈，定时调用GC.Collect()可以实现释放，但性能再怎么也会受影响。高并发情况下使用GC.Collect()也会出现问题。
无奈，定时调用GC.Collect()可以实现释放，但性能再怎么也会受影响。高并发情况下使用GC.Collect()也会出现问题。
wwwljh 2012-06-20
- 打赏
- 举报
silverlight中不光是MemoryStream内存不释放，其它点用内存的操作好像也不释放现象。
WPF/Silverlight应用程序长时间运行后会产生非常多的内存垃圾（内存泄露例外）：
主要解决方案有三种：
1） UIElement控件实例= null
2） 定时调用GC.Collect()
3） 让控件继承Idisposable接口，并实现相应逻辑
这三种方法都有一定的作用，但是实际使用中均往往难以达到预期效果。
内存不断增加导致运行二、三十分钟后浏览器即进入假死状态，Silverlight如果无法处理好内存的释放，命运或许终究一样。
那么我们是否还有其他更好的方法实现内存垃圾的释放？大家不妨做这么一个测试，以IE浏览器为例，当我们打开一个运行有Silverlight应用程序的页面后，
记录下任务管理器中该IEXPLORE.EXE的内存使用量，然后运行一段时间，再记录此时的内存使用量，最后将该页面最小化再还原回来，大家将看到该
IEXPLORE.EXE的内存使用量已被完全的释放干净，如同新开的网页一般。这老掉牙的东西已算不上什么技巧，但是却给了我们一条内存彻底释放的思路：既然
Silverlight应用程序是镶嵌在网页中的，我们能否通过该方法去释放内存呢？答案是肯定的。
我们是完全可以将这种方法无缝的嵌入到页面中去的。
在Winform/WPF中，实现该方法仅仅只需通过下面一段代码即可实现模拟释放内存。
[DllImport("kernel32.dll")]
public static extern bool SetProcessWorkingSetSize(IntPtr proc, int min, int max);
public void FlushMemory() {
GC.Collect();
GC.WaitForPendingFinalizers();
if (Environment.OSVersion.Platform == PlatformID.Win32NT) {
SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
}
}
但是Windows的API无法在Silverlight中使用，我们该怎么办呢？
再看下面这段代码：
<script type="text/javascript">
function intervalFlushMemory() {
setInterval(FlushMemory, 60000);
}
function FlushMemory() {
min.Click();
window.focus();
}
</script>
<body onload="intervalFlushMemory();">
……
<object id="min"
type="data:application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11">
<param name="Command" value="Minimize" />
</object>
<button onclick="FlushMemory();">释放内存</button>
……
</body>
我们可以使用一个Js的setInterval方法每间隔一段时间去自动释放内存，该方法原理为将浏览器最小化后再找回焦点，我们肉眼看到仅是页面闪了一下，再无任何其他感觉。就这么一瞬间，就算Silverlight应用程序导致浏览器占用了数百M的内存，照样完全释放无误。非常不幸的是，通过<object>实现内存释放的方法目前只能在IE中使用，而且由于诸多限制还无法很好的广泛使用，解决的最终方法目前我只想到两个：
1）
能否有相关的Silverlight的API直接实现类似功能，或者后台代码C#中去实现呢？
2）
通过将该<object>制作成控件并打包成cab，并加上数字签名，以ActiveX的形式让用户使用，实在是够麻烦的…
Silverlight还是个孩子，它的路还有很长要走；但我一直坚信：明天会更好。
WPF/Silverlight应用程序长时间运行后会产生非常多的内存垃圾（内存泄露例外）：
主要解决方案有三种：
1） UIElement控件实例= null
2） 定时调用GC.Collect()
3） 让控件继承Idisposable接口，并实现相应逻辑
这三种方法都有一定的作用，但是实际使用中均往往难以达到预期效果。
内存不断增加导致运行二、三十分钟后浏览器即进入假死状态，Silverlight如果无法处理好内存的释放，命运或许终究一样。
那么我们是否还有其他更好的方法实现内存垃圾的释放？大家不妨做这么一个测试，以IE浏览器为例，当我们打开一个运行有Silverlight应用程序的页面后，
记录下任务管理器中该IEXPLORE.EXE的内存使用量，然后运行一段时间，再记录此时的内存使用量，最后将该页面最小化再还原回来，大家将看到该
IEXPLORE.EXE的内存使用量已被完全的释放干净，如同新开的网页一般。这老掉牙的东西已算不上什么技巧，但是却给了我们一条内存彻底释放的思路：既然
Silverlight应用程序是镶嵌在网页中的，我们能否通过该方法去释放内存呢？答案是肯定的。
我们是完全可以将这种方法无缝的嵌入到页面中去的。
在Winform/WPF中，实现该方法仅仅只需通过下面一段代码即可实现模拟释放内存。
[DllImport("kernel32.dll")]
public static extern bool SetProcessWorkingSetSize(IntPtr proc, int min, int max);
public void FlushMemory() {
GC.Collect();
GC.WaitForPendingFinalizers();
if (Environment.OSVersion.Platform == PlatformID.Win32NT) {
SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);
}
}
但是Windows的API无法在Silverlight中使用，我们该怎么办呢？
再看下面这段代码：
<script type="text/javascript">
function intervalFlushMemory() {
setInterval(FlushMemory, 60000);
}
function FlushMemory() {
min.Click();
window.focus();
}
</script>
<body onload="intervalFlushMemory();">
……
<object id="min"
type="data:application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11">
<param name="Command" value="Minimize" />
</object>
<button onclick="FlushMemory();">释放内存</button>
……
</body>
我们可以使用一个Js的setInterval方法每间隔一段时间去自动释放内存，该方法原理为将浏览器最小化后再找回焦点，我们肉眼看到仅是页面闪了一下，再无任何其他感觉。就这么一瞬间，就算Silverlight应用程序导致浏览器占用了数百M的内存，照样完全释放无误。非常不幸的是，通过<object>实现内存释放的方法目前只能在IE中使用，而且由于诸多限制还无法很好的广泛使用，解决的最终方法目前我只想到两个：
1）
能否有相关的Silverlight的API直接实现类似功能，或者后台代码C#中去实现呢？
2）
通过将该<object>制作成控件并打包成cab，并加上数字签名，以ActiveX的形式让用户使用，实在是够麻烦的…
Silverlight还是个孩子，它的路还有很长要走；但我一直坚信：明天会更好。
