【转】.NET内存管理五大基础知识

以下文章来源于DotNET技术圈 ,作者RICKY LEEKS 1.小对象怎么处理的? 小型.NET对象被分配到小型对象堆(SOH)上。其中有3种:第0代,第1代和第2代。对象根据其寿命向上移动。 将新对象放在Gen 0上。当Gen 0充满时,.NET垃圾收集器(GC)运行,处理不再需要的对象,并将其他所有内容移至Gen1。如果Gen 1充满,则GC再次运行,也可以将Gen 1中的对象移动到Gen 2中。 当Gen 2变满时,将发生GC完全运行。这将清除不需要的Gen 2对象,将Gen 1对象移至Gen 2,然后将Gen 0对象移至Gen 1,最后清除所有未引用的内容。每次运行GC之后,都会压缩受影响的堆,以将仍在使用的内存保持在一起。 这种代代相传的方法可确保事情高效运行-耗时的压缩过程仅在绝对必要时才会发生。 注意:如果您在Gen 2中看到大量的内存,则表明内存已被保留很长时间,并且可能存在内存问题。这是内存分析工具可以派上用场的地方。 2.较大的对象会怎样? 大于85 KB的对象被分配到大对象堆(LOH)。由于复制大块内存的开销,它们没有被压缩。当发生完整的GC时,未使用的LOH对象的地址范围将记录在可用空间分配表中。 分配新对象后,将在此可用空间表中检查足以容纳该对象的地址范围。如果存在,则将对象分配到那里,如果不存在,则将对象分配到下一个可用空间。 由于对象不太可能是空地址范围的确切大小,因此对象之间几乎总是会留有小块内存,从而导致碎片。如果这些块小于85 KB,则根本没有重用的可能性。因此,随着分配需求的增加,即使碎片空间仍然可用,也会保留新的段。 此外,当需要分配大对象时,.NET还是倾向于将对象附加到末尾,而不是运行昂贵的Gen 2 GC。这对性能有好处,但是是导致内存碎片的重要原因 3.垃圾收集器可以在不同的模式下运行以优化性能 .NET通过为GC提供多种模式来解决性能与堆效率之间的权衡问题。 工作站模式为用户提供了最大的响应速度,并减少了由于GC造成的暂停。它可以作为“并发”或“非并发”运行,指的是运行GC的线程。默认值为并发,它为GC使用单独的线程,因此应用程序可以在GC运行时继续执行。 服务器模式可为服务器环境提供最大的吞吐量,可伸缩性和性能。在服务器模式下,段大小和生成阈值通常比工作站模式大得多,这反映了对服务器的更高要求。 服务器模式在多个线程上并行运行垃圾回收,为每个逻辑处理器分配一个单独的SOH和LOH,以防止线程相互干扰。 .NET框架提供了一种交叉引用机制,因此对象仍然可以在堆之间相互引用。但是,由于应用程序响应能力不是服务器模式的直接目标,因此在GC期间,所有应用程序线程都将被挂起。 4.引用不足会在性能和内存效率之间折衷 弱对象引用了GC根的替代来源,使您可以保留对象,同时在GC需要时可以收集对象。它们是代码性能和内存效率之间的折衷。创建对象需要占用CPU时间,但保持加载状态需要占用内存。 弱引用特别适用于大型数据结构。例如,假设您有一个允许用户浏览大型数据结构的应用程序,他们可能会返回其中的一些数据。您可以将任何强引用转换为他们浏览的结构为弱引用。如果用户返回到这些结构,则可以使用它们,但如果没有,GC可以根据需要回收内存。 5.对象固定可以创建在托管和非托管代码之间传递的引用 .NET使用一种称为GCHandle的结构来跟踪堆对象。GCHandle可用于在托管域和非托管域之间传递对象引用,.NET维护一个GCHandles表以实现此目的。GCHandle有四种类型,包括固定的,用于将对象固定在内存中的特定地址。 对象固定的主要问题是它可能导致SOH碎片化。如果将对象固定在GC期间,则根据定义,该对象无法重定位。根据您使用固定的方式,它会降低压缩的效率,在堆中留下间隙。避免这种情况的最佳策略是在很短的时间内锁定,然后释放。

June 1, 2020

用Windbg来分析.Net程序的dump

用Windbg来分析.Net程序的dump 1. 什么是Windbg WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。 WinDbg是微软很重要的诊断调试工具: 可以查看源代码、设置断点、查看变量, 查看调用堆栈及内存情况。 Dump文件是进程的内存镜像, 可以把程序的执行状态通过调试器保存到dump文件中 2. Windbg可以解决以下问题 ◆ 内存高 ◆ CPU高 ◆ 程序异常 ◆ 程序Hang死 3. 使用windbg进行调试分析的两种方式 使用windbg调试器attach到需要调试的进程。(会暂停进程的运行) 抓取进程的dump文件,使用windbg分析dump 下载地址:https://technet.microsoft.com/en-us/sysinternals/dd996900 下载之后为压缩包,将文件解压。通过dos命令来生成dump文件。下面为一条语句为示例 procdump -ma -c 0 -s 3 -n 2 sqlservr.exe -o E:\dumps\ 这条语句的意思为:当sqkservr.exe这个进程运行时间cpu的占用超过0%,时间超过3秒,则在E:\dumps下生成一个dump文件。一直到生成2个为止。下面为命令介绍 -ma 生成full dump, 即包括进程的所有内存. 默认的dump格式包括线程和句柄信息. -c 在CPU使用率到达这个阀值的时候, 生成dump文件. -s CPU阀值必须持续多少秒才抓取dump文件. -n 在该工具退出之前要抓取多少个dump文件. -o dump文件保存目录. Sqlservr.exe可替换为进程的ID

June 1, 2020

看完Orchard Core的一些随感

这个项目的框架是微软顶级工程师的杰作,太牛了,终于理解为什么各类开发IDE都是海外工程师写出来了,框架设计优美、代码精炼、扩展性超强、考虑全面。ps:国内IT软件方面至少落后欧美10年(那些把开源改改就说国产世界第一就别拿来丢脸了),得益于开源和github,我们才有机会保持这个差距。 国内对C#和.NET总是有一些误解。比如.NET Core,海外已经用得如火如荼了,社区非常活跃,并且各种新的开发理念和工具极大提高效率。我在BAT写过代码,说实话他们的软件架构理念都是实用为主,并没有从工程学角度去发展,所以只适合特点场景,但是他们垄断中国码农的话语权,导致后来者c#大都被误解。这无形中导致国内软件开发起码落后海外10年。举一个最简单例子,现在大公司也有devops,但是放到中小型公司,他们很难运用bat的这套东西,而阿里云对devops支持太差了,反观aws和azure几乎是完美支持,这里面有国情原因,也有c#被误解的原因。 我可以毫无客气地说:国内对.net的误解,其实就是落后又自大的一个缩影。看看现在华为、国产软件时不时世界第一的“亩产万金”的论断。

October 15, 2019

[转]C#语言历史版本特性(C# 1.0到C# 8.0汇总)

历史版本 C#作为微软2000年以后.NET平台开发的当家语言,发展至今具有17年的历史,语言本身具有丰富的特性,微软对其更新支持也十分支持。微软将C#提交给标准组织ECMA,C# 5.0目前是ECMA发布的最新规范,C# 6.0还是草案阶段,C# 7.1是微软当前提供的最新规范。 这里仅仅列个提纲,由于C# 5.0是具有ECMA标准规范的版本,所以选择C# 5.0作为主要版本学习,并专题学习C# 6.0,7.0版本新特性。 C#语言规范GitHub库参见:https://github.com/dotnet/csharplang C#语言路线图及开发中的特性参见: https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md 语言版本 发布时间 .NET Framework要求 Visual Studio版本 C# 1.0 2002.1 .NET Framework 1.0 Visual Studio .NET 2002 C# 1.1\1.2 2003.4 .NET Framework 1.1 Visual Studio .NET 2003 C# 2.0 2005.11 .NET Framework 2.0 Visual Studio 2005 C# 3.0 2007.11 .NET Framework 2.0\3.0\3.5 Visual Studio 2008 C# 4.0 2010.4 .NET Framework 4.0 Visual Studio 2010 C# 5.0 2012.8 .NET Framework 4.5 Visual Studio 2012\2013 C# 6.0 2015.7 .NET Framework 4.6 Visual Studio 2015 C# 7.0 2017.3 .NET Framework 4.6.2 Visual Studio 2017 C# 7.1 2017.6 .NET Framework Visual Studio 2017 v15.3预览版 C# 8.0 待发布 .NET Framework 4.7.1 Visual Studio 2017 v15.7 C# 1.0 特性 第1个版本,编程语言最基础的特性。 ...

October 10, 2019

关于C#和.NET以及自己未来的一些计划

这几天把.NETCONF所有的视频都看了一遍,感叹微软的开放力度和对C#及.NET的推进力度。我写过Delphi、VB、C、C++、C#、Object-C、PHP、JAVA、Python,这一路过来总觉得太分散了,很难真正投入到推动一门语言的地步,现在看来,C#是初恋也是最爱,真不能在乱“移情别恋”了。未来最多使用Python进行一些ML(机器学习)涉及的方面的数据工作。 针对C#和.NET我一定持续关注,而且专注于她,这是工作需要,也是自己的发展需要。 1、全面梳理C#这门语言,虽然我已经写了12年C#了。 实际行动:把微软的文档看一遍,把那几本经典的书读完。(2019到2020) 2、应用.NET Core 3.0及未来版本。 实际行动:把公司的一个项目做成兼容linux平台。(2019) 3、研究Orchard Core项目。 实际行动:把自己的blog都迁移过来。(2019到2020) 4、研究ABP项目,顺便研究微服务架构和DDD结构。 实际行动:在公司的一个项目中完成。(2019到2020) 5、机器学习ML.NET研究和Python 实际行动:自己建模完成一些数据分析和预测。(2019起步,长期工作) 6、学习Azure、AWS技术和DevOps 实际行动:考下AWS证书,并在公司一个项目中完成Azure的DevOps。(2020到2021) 另外,学习nopCommerce和CSLA .NET两个开源项目的特点,吸收特长;学习Angular和Vue前端框架。

October 1, 2019

.NET Core 3.0 正式公布

根据微软博客的介绍,开发者可以面向 Windows、MacOS 以及 Linux 等系统平台下载 .NET Core 3.0 : .NET Core 3.0 SDK 与运行时 Snap 安装程序 Docker 镜像 此外, ASP .NET Core 3.0 与 EF Core 3.0 也已经一同发布。 Visual Studio 2019 16.3 与 Visual Studio for Mac 8.3 亦同时发布,且需要更新才能确保 .NET Core 3.0 与 Visual Studio 的协同使用。.NET Core 3.0 为 Visual Studio 2019 16.3 中的组成部分,开发者可以选择直接升级至 Visual Studio 2019 16.3,从而立刻获取 .NET Core。 感谢所有为 .NET Core 3.0 做出贡献的朋友们!此次最新版本的发布源自数百位团队成员的努力,也包括技术社区的重大贡献。 发行说明: .NET Core 3.0 发行说明 .NET Core 2.2 -> 3.0 API 的区别 .NET Core 3.0 贡献者名单 GitHub 发行版 关于 .NET Core 3.0 的 GitHub 问题解答 3.0 版本,开发者需要了解什么? 在深入探究 .NET Core 3.0 中的全部新功能之前,我们首先需要强调几项关键性的改进与指导内容。以下是整理出的要点清单: ...

September 25, 2019

[转]SignalR Core 尝鲜-A developer's tour of SignalR Core Alpha

几个月前,SignalR Core 团队发布了一个非官方版本的 ASP.NET Core SignalR。为此,开发人员有机会了解其工作原理以及 ASP.NET SignalR 与 Signal Core 新架构之间的区别。 SignalR Core 中移除了哪些特性 通过对比两个版本的 SignalR 可以发现,新版本不再支持一些重要的特性。首先是移除了对 jQuery 和其他第三方类库的依赖,因为新版本的 JavaScript 客户端是使用 TypeScript 开发的。其次是自动连接后的消息重放功能,移除该功能主要是出于性能方面的考虑。服务器需要为每一个连接维护一个缓冲区,用于保存消息,以便后续重新发送。当客户端断开连接,可以尝试重新恢复连接,然后将未发送的消息发送给客户端。可以想象,如果有很多客户端断开连接,而且每个客户端都发送大量的消息,对于服务器来说是个很大的负担。另一个被 SignalR 团队移除特性是多 Hub 端点,所以,在新版本里,每个连接只有一个 Hub。 新版本的 SignalR Core 不再支持横向扩展(Scale Out)模型,原因是 MessageBus 被当成了横向扩展的“万灵丹”,但它实际上只支持Azure Service Bus、Redis 和 SQL Server。在实际的协作场景当中(客户端到客户端),随着客户端和消息数量的增长,通过以上三种方式进行横向扩展会有瓶颈问题。 不过,我认为,移除横向扩展功能这一决定有点太过激进,因为在某些场景下,MessageBus 仍然十分有用。例如,在将 SignalR 作为一个广播服务器时,它可以控制发送消息的数量。而在 SignalR Core 的 alpha 版本中,开发者可以根据实际情况选择是否进行横向扩展,如业务需求、系统约束或基础设施,这种设计更加“可插拔”。SignalR Core 团队提供了一个使用 Redis 进行横向扩展的示例。其他扩展方式可能会被包含在 SignalR Core 的最终版中。 最后一个被移除的功能是多服务器间的双向复制(backplane),因为这个功能会在服务器场生成太多的流量。ASP.NET SignalR 通过 MessageBus 在服务器间复制每一个消息,因为客户端无法直接连接到服务器场,而现在,SignalR 使用粘性会话来避免在所有服务器间复制消息。这样一来,SignalR Core 就可以知道哪个客户端连接到了哪台服务器上。 SignalR Core 中增加了哪些新特性 现在让我们来看一下 SignalR Core 带来了哪些新的特性。首先是使用了二进制协议来发送和接收消息。在 ASP.NET SignalR 中只能使用 JSON 格式的文本来发送和接收消息,而现在则可以使用二进制协议,该二进制协议基于MessagePack序列化格式,比 JSON 更快、体积更小。 ...

July 19, 2019

关于.NET Core情况

这几天终于抽出空啦看微软的Build 2019,看到.NET Core 3.0及相关技术的详细介绍,并且了解.NET的未来规划,感叹微软的伟大。 上图是.NET Core的web开发部分。 上图是.NET 平台大统一设计。 上图是.NET未来的Roadmap。 这就叫做技术领域的一统江湖。二十年前很多人嘲笑Windows的垄断和Microsoft的不开源(现在依然有老古董如此认为),如今,Sun寄人篱下并且靠着Java专利法残喘苟活。我一直觉得微软汇聚的是软件世界最优秀的工程师,这些人要是投身开源代码,那是很恐怖的,短短不到5年时间,微软现在成为开源代码贡献最大的公司。 如今.NET Core 在海外若日中天,当国内经济持续下滑,人力成本持续提高,你们就会想到用.NET Core了,一个公司只需要三名码农就可以搞定后端、前端、移动开发。不过很可惜,公司的人力部门都听CTO的,而这群Java养出来的没落贵族是不会自己变革的。 ​​​​

July 17, 2019

[转]WebAssembly 和 Blazor:解决了一个存在十年的老问题

本文要点 WebAssembly 是一种新的客户端技术,可以在所有现代浏览器(包括移动浏览器)中实现近乎原生的性能,而且不需要插件。 许多语言,包括 C、C#、Go 和 Rust,都可以编译成面向基于栈的 WebAssembly 虚拟机的代码。 .NET 代码可以在任何地方运行,包括浏览器内部。 Blazor 是一个客户端库,它在 WebAssembly 上使用.NET 来支持借助 Razor 模板使用 C# 编写的单页应用程序。 Blazor 支持代码重用和将遗留代码移植到现代 Web 应用程序的能力。 在 2019 年 4 月中旬,微软悄悄地推出了一个年轻的框架,从“一切皆有可能”的实验阶段过渡到“我们致力于实现这一目标”的预览版。这个框架名为Blazor,因为它在浏览器中运行,并利用了一个名为 Razor 的模板系统或“视图引擎”,促成了这个.NET 开发人员几乎放弃了的场景。它不仅允许开发人员使用 C# 构建客户端代码(不需要 JavaScript),还允许开发人员在没有插件的情况下在浏览器中运行现有的.NET 标准 DLL。 Blazor 有两种托管模式。本文主要关注客户端版本。你可以阅读“Blazor 服务器端托管模型”了解更多关于服务器端版本的信息。 Silverlight 的希望 在任何地方运行.NET 的梦想始于 2006 年,当时有一个名为“Windows Presentation Foundation/Everywhere(WPF/E)”的应用程序框架以 Silverlight 的形式向公众发布。第一个版本支持通过 WPF 引入的声明性用户界面,即可扩展应用程序标记语言(Extensible Application Markup Language,简称 XAML)。该平台提供了对 UI 元素的细粒度控制,并提供了自己的文档对象模型(DOM),可以通过 JavaScript 访问。 当 Silverlight 2 在 2008 年发布时,它通过一个作为浏览器插件运行的公共语言运行时(CLR)实现.NET 的完全支持,从而加快了采用速度。开发人员可以使用任何.NET 语言来构建 Web 应用程序,利用成熟的数据绑定模式,如 Model-View-ViewMode(MVVM),并使用 REST 或 Windows Communication Foundation(WCF)客户端与 Web API 通信。看起来,.NET 开发人员可以摆脱 JavaScript 的束缚,不用再担心跨浏览器测试,而是专注于一个具有公共代码库的平台来交付他们的应用程序。 ...

July 12, 2019

.NET Core 3.0 Preview 5发布

今天我们非常高兴发布 .NET Core 3.0 Preview 5,它包含了新的Json serializer,支持发布单执行文件,并且更新到新的runtime roll-forward,BCL也做了一些改动。 目前可以下载.NET Core 3.0 Preview 5安装到Windows, macOS and Linux.另外,ASP.NET Core和EF Core也发布了。 具体英文地址:https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/

May 28, 2019