不动产登记网站建设,个人开通微信小程序,自己做网站后台,做网站app垃圾收集 java通过从您的应用程序学习企业APM产品#xff0c;发现更快#xff0c;更有效的性能监控。 参加AppDynamics APM导览#xff01; “无需为用户编写将寄存器返回到自由存储列表的程序。” 这条线#xff08;以及随后的十几条线#xff09;被埋在约翰麦卡锡发现更快更有效的性能监控。 参加AppDynamics APM导览 “无需为用户编写将寄存器返回到自由存储列表的程序。” 这条线以及随后的十几条线被埋在约翰·麦卡锡John McCarthy具有里程碑意义的论文中 该论文发表于1960年“符号表达式的递归函数及其由机器进行的计算”。这是对自动内存的第一个已知描述。管理。 在指定如何在Lisp中管理内存时McCarthy能够排除显式的内存管理。 因此麦卡锡McCarthy减轻了开发人员对手动内存管理的烦恼。 使这个故事真正令人惊奇的是这几个词激发了其他人将某种形式的自动内存管理也称为垃圾收集 GC整合到此后开发的四分之三的更广泛使用的语言和运行时中。 该列表包括两个最受欢迎的平台即Java的虚拟机 JVM和.NET的公共语言运行时 CLR以及Google即将推出的Go Lang 。 GC不仅存在于大型企业中还存在于移动平台上例如Android的DalvikAndroid Runtime和Apple的Swift。 您甚至可以在Web浏览器以及诸如SSD之类的硬件设备上找到运行的GC。 让我们探讨一些为什么行业更喜欢自动化而不是手动内存管理的原因。 自动内存管理的开端 那么麦卡锡如何设计自动内存管理 首先Lisp引擎将Lisp表达式分解为子表达式每个S表达式都存储在链接列表中的单个单词节点中。 节点是从空闲列表中分配的但是不必将它们返回到空闲列表直到它为空。 一旦空闲列表为空运行时就会跟踪链接列表并标记所有可到达的节点。 接下来它扫描包含所有节点的缓冲区并将未标记的节点返回到空闲列表。 重新填写自由列表后应用程序将继续。 今天这被称为单空间就地跟踪垃圾收集。 该实现非常简单它只需要处理一个非循环定向图其中所有节点的大小都完全相同。 只有一个线程运行并且该线程执行了应用程序代码或垃圾回收器。 相比之下当今JVM中的收集器必须应对循环和节点大小不一致的有向图。 JVM是多线程的在多核CPU可能是多插槽的主板上运行。 因此今天的实现要复杂得多以至于GC专家很难预测任何给定情况下的性能。 进度缓慢垃圾回收暂停时间 当Lisp垃圾收集器运行时应用程序停止了。 在Lisp的初始版本中收集器通常占用30到40的CPU周期。 在1960年代的硬件上这可能导致应用程序停顿几分钟这被称为“世界停止” 。 好处是分配几乎对应用程序吞吐量完成的有用工作量没有任何影响。 此实现突出显示了暂停时间和对应用程序吞吐量的影响之间的持续斗争这一斗争一直持续到今天。 通常收集器的暂停时间特性越好它对应用程序吞吐量的影响就越大。 Java当前的所有实现都带有暂停时间/开销成本。 并行收集具有较长的暂停时间和较低的开销而大多数并发的收集器具有较短的暂停时间并消耗更多的计算资源包括内存和CPU。 任何GC实现者的目标都是最大程度地保证保证变种线程接收的最少处理器时间这一概念称为最小变种利用率MMU。 即使这样当前的GC开销也可以很好地运行在5以下而在典型的C 应用程序中您会遇到15到20的开销。 那么为什么不像在Java应用程序中那样感到这种开销呢 由于开销在C / C 运行时间中平均分布因此最终用户看不到它。 实际上有关托管内存的最大抱怨是它在无法预测的时间内暂停了您的应用程序不可预测的时间。 垃圾收集进展 Sun Java最初的垃圾收集器并没有改善垃圾收集的形象。 它的单线程单行距实现使应用程序停滞了很长时间并极大地拖累了分配率。 直到Java 2才引入了代内存池方案以及并行的主要是并发的和增量的收集器。 尽管这些收集器提供了改进的暂停时间特性但是暂停时间仍然是个问题。 而且这些实现非常复杂以致大多数开发人员不太可能具有调整它们的必要经验。 为了使情况更加复杂IBMAzul和RedHat拥有一个或多个自己的垃圾收集器-每个垃圾收集器都有各自的历史优势和怪癖。 此外包括SAPTwitterGoogle阿里巴巴在内的许多公司都拥有自己的内部JVM团队并带有Garbage收集器的修改版本。 随着时间的流逝增加了备用且更复杂的分配路径导致分配开销图片的巨大改进。 例如JVM中的快速路径分配现在比C / C 中的典型分配快大约30倍。 麻烦之处在于只有可以通过转义分析测试的数据才有资格进行快速路径分配。 幸运的是我们的绝大多数数据都通过了此测试并从此备用分配路径中受益。 另一个优点是撤离收集器带来的成本降低和成本模型简化。 在这种方案中收集器将实时数据复制到另一个内存池。 因此不存在恢复短命数据的成本。 这并不是分配广告恶心的邀请因为每次分配都会产生成本并且高分配率会触发更频繁的GC活动并累积额外的复制成本。 抽空收集器有助于提高GC的效率和可预测性但是仍然存在大量资源成本。 那导致我们记忆。 内存管理要求您保留的内存至少是手动内存管理需要的五倍。 开发人员有时肯定知道应该释放数据。 在这些情况下显式释放而不是通过决策使收集者有理由便宜。 正是这些成本使苹果最初选择了Objective-C的手动内存管理。 在Swift中Apple选择使用引用计数。 他们为弱引用和自有引用添加了注释以帮助收集器应对循环引用。 还有其他无形的或难以衡量的成本可以归因于运行时的设计决策。 例如失去对内存布局的控制权可能导致应用程序性能受L2高速缓存未命中和高速缓存行密度的支配。 在这些情况下性能下降很容易超过101。 未来实现者面临的挑战之一是如何更好地控制内存布局。 回顾一下当第一次将Lisp引入Lisp时GC的性能如何以及通向目前状态的漫长而又令人沮丧的道路很难想象为什么任何构建运行时的人都想使用托管内存。 但是请考虑一下如果您手动管理内存则需要访问底层的参考系统-这意味着该语言需要添加语法来操作内存指针。 依靠托管内存的语言始终缺乏管理指针所需的语法因为可以保证内存一致性。 这保证了所有指针都将指向它们应指向的位置而如果您碰巧踩了它们则无需悬空空指针等待耗尽运行时间。 如果允许开发人员直接创建和操作指针则运行时无法保证。 另外将其从语言中删除会消除间接性这是开发人员更难掌握的概念之一。 漏洞经常是由于从事精神体操的开发人员需要处理许多竞争问题并弄错而导致的。 如果这种混合包含通过应用程序逻辑进行推理以及手动内存管理和不同的内存访问模式则错误可能会出现在代码中。 实际上依赖手动内存管理的系统中的错误是当今系统中最严重和最大的安全漏洞来源之一。 为了防止这些类型的错误开发人员总是要问“我是否仍然有可行的参考资料来阻止我释放这些资料” 这个问题的答案通常是“我不知道”。 如果将对这些数据的引用传递到系统中的另一个组件则几乎不可能知道是否可以安全地释放内存。 众所周知指针错误会导致数据损坏或者在最佳情况下会导致SIGSEGV。 从图片中删除指针往往会产生一个更具可读性更易于推理和维护的代码。 GC知道何时可以回收内存。 此属性使项目可以安全地使用第三方组件这在使用手动内存管理的语言中很少发生。 结论 在最佳状态下内存管理可谓是一项繁琐的簿记任务。 如果可以将内存管理排除在待办事项之外那么开发人员往往会提高工作效率并产生更少的错误。 我们还已经看到GC并不是万能药因为它有其自身的一系列问题。 但值得庆幸的是向更好的实现迈进的步伐还在继续。 Go Lang的新收集器结合了引用计数和跟踪功能以减少开销并最大程度地减少暂停时间。 Azul声称已通过大大降低暂停时间来解决GC暂停问题。 Oracle和IBM一直在致力于收集器他们认为收集器更适合包含大量数据的超大堆。 RedHat已与Shenandoah展开竞争Shenandoah的目标是从运行时间中完全消除暂停时间。 同时Twitter和Google继续改善现有的收藏家因此它们继续对新的收藏家具有竞争力。 通过从您的应用程序学习企业APM产品发现更快更有效的性能监控。 参加AppDynamics APM导览 翻译自: https://www.javacodegeeks.com/2017/02/javas-built-garbage-collection-will-make-life-better-time.html垃圾收集 java
