写点什么

对 IDisposable 和静态分析的提议:DisposeUnused 属性

  • 2019-10-23
  • 本文字数:1734 字

    阅读完需:约 6 分钟

对IDisposable和静态分析的提议:DisposeUnused属性

当 .NET 初创的时候,关于IDisposable该如何使用存在一定的不确定性。结果,IDisposable的应用方式过于激进,许多种类的类都需要空的 Dispose 方法。这给静态分析工具带来了一些问题,它们无法将实际缺少Dispose调用与误报区分开来。


为了理解始末缘由,我们需要回过头看一下 CLR 早期的历史以及垃圾收集是如何运行的。最初,CLR 的目的在于是作为 Visual Basic 的新运行时,在 20 世纪 90 年代末 Visual Basic 是基于 COM 的。在 COM 模型下,对象会有一个引用计数。在引用创建和销毁的时候,引用计数会随之进行更新,如果计数变成零,对象就会被释放。这样的话,就形成了一个具有确定性的垃圾收集模型,在这种模型中,我们可以确切地知道该在什么时候清理资源。


引用方式的垃圾收集模型的最明显缺点就在于它很容易出现内存泄露。如果我们创建了一系列的对象,它们之间互相循环引用的话,每个对象都会让其他对象的引用计数无法降低到零,从而会出现内存泄露。在多线程环境中,它还会产生性能问题,因为在调整引用计数的时候,需要用到锁。


在开发的早期,微软决定采用标记-清理(mark-and-sweep)垃圾收集器来让 CLR 避免这些问题。随着 Java 的流行,这种方式在社区中得到了普遍的认可。但是,这种方式的 GC 并不能确定地释放资源,这使得它不适合用于数据库连接、文件处理和其他高度受限的资源。因此,IDisposable 应运而生。


与此同时,微软正在试验“组件”的理念。组件的概念从来没有被很好地定义。在这方面,有Component类,以及像IComponentIContainerISite这样的接口。在将近 20 年之后,文档中也只有一个很模糊的注释:“应用程序之间的对象共享”。其想法大概和 COM 类似,也就是某个应用可以直接与其他程序进行交互。但是,这并没有达到目的,所以被埋没在历史的故纸堆中了。


而在 Windows Forms 中,有一个不同的“组件”概念,它真正的意思是“可以放到表单/窗口(form/window)中的内容”。除了像文本框这样的实际 UI 元素之外,还包括添加了特定功能的对象,如计时器。这来自 VB 6 编程时代,当时几乎所有想使用的内容都必须要放到表单中。甚至数据库连接和命令也可以直接放到表单中。


这也就是为什么我们看到很多毫不相关的对象也标记成了IDisposable。像DataTableSqlCommand并没有要处理的非托管资源,但是在过去我们错误地认为最好将它们放到表单中,所以它们继承了Component类。而 Component 是 disposable 的,所以我们可以选择何时关闭代理对象。

静态分析

随着静态分析逐渐从高级工具变成了每个开发人员都该使用的工具,关于 disposable 对象不断增长的告警越来越成为一个问题。对于像SqlCommand这样短期存活的对象来说,这还不算太糟糕,因为可以很容易地使用 using 语句对其进行包装,而不需要考虑该语句实际上并没有执行任何操作。


DataTable这样的类就比较困难了。这是一个长期存活的对象,它所使用的地方可能距离创建它的地方非常远。除非设置为 suppressed 或禁用,否则静态分析工具将会报告 DataTable 和类似对象有未处理处理的告警和错误。

DisposeUnusedAttribute 提议

“最佳”方案是彻底移除所有无用的Dispose方法。但是,这并不是可行方案,因为这样会破坏向后的兼容性。


Edward Brey 提出了一个相当简单而优雅的解决方案。他建议创建一个DisposeUnused属性来屏蔽静态分析工具。子类不会继承此属性。


但是,这个设计也并非尽善尽美。一旦DisposeUnused用到了某个类上,移除它将会是破坏性的变更。对于 DataTable 来说,这并不是什么问题,不过,Stephen A. Imhoff 提供一个这样的样例。


这实际上会更糟糕,因为现在你可能会说“好的,忽略该契约,我就是这样声明的”,如果某个类型突然需要 dispose 某个资源的话(比如说,MemoryStream 要为大型数组或其他内容分配一个原生数组),那么你的消费者需要执行 dispose 操作,但是你之前却告诉人家不需要这样做……


另一个问题是你并不是总能知道变量里有什么。假设有一个类型为 Component 的变量。在编译时,我们无法判断放入变量的内容是否需要 dispose 处理。因此,更有意义的做法是只将DisposeUnused用到密闭类(sealed classed)中,这些类是无法子类化的。


原文链接:


A Proposal for IDisposable and Static Analysis: DisposeUnused Attribute


2019-10-23 08:001428

评论 1 条评论

发布
用户头像
对C#来说Attribute别翻译为属性更好些。记得王垠较早前就吐槽C#的这个了。
2019-10-23 17:52
回复
没有更多了
发现更多内容

「亲测有效」ChatGPT Plus会员/GPT4开通方法 — 仅需支付宝或微信

跨境

openai VISA ChatGPT

技术人的2023漫谈AI语音体验之路

RoSofteg

#技术人的2023总结

1688店铺详情数据接口(1688.seller_info)丨1688API接口

tbapi

1688API接口 1688店铺详情接口 1688公司详情接口 1688店铺评分接口

云原生容器编排问题盘点,总结分享年度使用Kubernetes的坑和陷阱

码界西柚

Kubernetes 云原生 问题总结 #技术人的2023总结 方案分析

无表情包不MEME,PADD 最具潜力的BRC20 meme

股市老人

Java中的秘会厅ThreadLocal你了解吗?

架构虫哥

Java 并发编程 ThreadLocal java 并发 Java并发编程

paypal实操常见问题——绑卡篇

跨境

PayPal

一次不算太好的 E3PO 项目体验

战场小包

开源 视频流 E3PO

【新手入门】如何java来求各种数

极客罗杰

强大的高效视频处理框架——BMF

白日梦

视频处理 多媒体 BMF

按图搜索1688商品(拍立淘)接口(1688.item_search_img) 丨1688图片搜索API接口

tbapi

1688图片搜索接口 按图搜索1688商品数据接口 1688图片搜索商品接口 1688拍立淘接口 1688图片搜索API接口

我的2023技术总结:以梦为马,不负年华

言程序

大模型 #技术人的2023总结

大模型的应用前景:从自然语言处理到图像识别

啊川..

癸卯年之大模型经验总结

穆雄雄

AI大模型 大模型时代 雄雄的小课堂

大数据技术年度总结 | 主赛道

Emo_TT

大数据 可视化 年终总结

大模型:未来的智能方向

在书中成长

AI 大模型 ChatGPT

在iOS应用中使用实时活动与灵动岛

珲少

云原生技术的探索与实践| 主赛道

Emo_TT

云原生 年终总结

打造新一代云原生"消息、事件、流"统一消息引擎的融合处理平台

码界西柚

RocketMQ 云原生 #技术人的2023总结 火山引擎开发者社区 2023年技术盘点

大数据安全与隐私保护:构建可信的数据生态系统

范艺笙冉

E3PO:360°视频模拟的探索与发现

RoSofteg

E3PO

结束不是终点,而是新的起点

晴空万里

2023-12-30:用go语言,给你一个下标从 0 开始的整数数组 nums ,它包含 n 个 互不相同 的正整数, 如果 nums 的一个排列满足以下条件,我们称它是一个特别的排列。 对于 0 <

福大大架构师每日一题

福大大架构师每日一题

技术人的 2023 总结之无处不在的AI

六月的雨在InfoQ

AI 2023 #技术人的2023总结

KubeWharf: 云原生分布式操作系统体验部署

RoSofteg

KubeWharf

1688店铺所有商品数据接口(1688.item_search_shop)丨1688API接口

tbapi

1688API接口 1688商品数据接口 1688店铺所有商品数据接口 1688整店商品数据接口

技术人的2023年总结:以梦为马,不负年华

言程序

大模型 AIGC 2023年技术盘点

ChatGPT使用注意事项有哪些?

跨境

openai VISA ChatGPT

记录时光爬过2023年AI所留下痕迹,那么24年的AI还神秘吗?

鸿蒙之旅

AI

云原生架构未来发展趋势,探索容器技术未来的发展趋势

Tech技术攻关

云原生 未来技术趋势 #技术人的2023总结 架构方向

对IDisposable和静态分析的提议:DisposeUnused属性_语言 & 开发_Jonathan Allen_InfoQ精选文章