我听说垃圾收集导致软件设计不好。真的吗?确实,我们不关心垃圾收集语言中对象的生命周期,但这对程序设计有影响吗?
答案 0 :(得分:2)
如果某个对象要求其他对象代表其执行某些操作,直到另行通知为止,则该对象的所有者应在其不需要其服务时通知它。让代码放弃这些对象而不通知他们不再需要他们的服务将是糟糕的设计,但这在垃圾收集框架中和在非GC框架中一样真实。
正确使用的垃圾收集框架具有两个优点:
在许多情况下,创建对象是为了在其中封装值,并且对对象的引用作为该数据的代理传递。接收此类引用的代码不应关心这些相同对象是否存在其他引用,或者它是否包含最后存活的引用。只要有人持有对象的引用,就应该保留数据。一旦没有人再需要这些数据,就应该不再存在,但没有人应该特别注意。
在非GC框架中,尝试使用已处置对象通常会生成无法可靠捕获的未定义行为(并且可能允许代码违反安全策略)。在许多GC框架中,可以确保使用已处置资源的尝试将被确定性地捕获并且不会破坏安全性。
在某些情况下,垃圾收集将允许程序员“躲避”比非GC系统可容忍的设计更糟糕的设计。但是,基于GC的框架也允许使用许多良好的编程模式,这些模式在非GC系统中无法有效实现。例如,如果一个程序使用多个工作线程来找到问题的最佳解决方案,并且有一个UI线程,它周期性地想要显示到目前为止找到的最佳解决方案,那么UI线程会想知道它何时要求状态更新它将获得已找到的 解决方案,但不希望为工作线程增加必要的同步负担,以确保它具有绝对最新的解决方案。
在非GC系统中,线程同步是不可避免的,因为UI线程和工作线程必须协调谁将删除在显示时变得过时的状态对象。但是,在基于GC的系统中,GC可以判断UI线程是否能够在替换状态对象之前获取对状态对象的引用,从而解决对象是否需要保持活动足够长时间才能使用UI线程来显示它。 GC有时必须强制线程同步才能找到所有可访问的引用,但GC的偶尔同步可能比非GC系统中所需的频繁线程同步更能降低性能。