今天我遇到了一个幽灵方法

今天我遇到了一个幽灵方法,诡异至极,虽然我确信这个方法没有被调用过,无论是通过打断点,还是添加输出代码,我都在运行时验证了这一点,但诡异的是,那些只受该方法影响的变量,就是发生了改变。所以这是一个没有被调用,却又明显调用过的方法,一个幽灵方法。
这个方法大概是这样的:

public class Weight {
    ......
    public virtual Weight setValue(double weight) {
            isSet = true;
            nextWeight1 = null;
            nextWeight2 = null;
            this.trueWeight = (float)weight;
            return this;
        }
}

该方法会在值被设置的时候,做一些清理工作。
但出现幽灵现象的其实不是这个方法本身,问题发生在Weight的子类BiWeight身上。在我的逻辑中BiWeight的对象是没有机会调用到这个方法的,因此我也就没有重载这个方法在BiWeight中的实现。但最近我在调试中,需要查看BiWeight的内部变量的值的时候,却发现了一些诡异的现象。

调试时看到的内存状态

我检查了代码,确认唯有在这个方法中,isSet才有可能会被设为true,因此这个方法千真万确地被调用过。

为了确定这一点,我在BiWeight中重载了这个方法,并加了断点。

运行,断点没有被触发。我怀疑可能是被编译器优化掉了。

于是我添加了输出语句。

运行,没有相应的输出。
这么看来,这个方法应该没有被调用才对。
于是我有修改了实现,不再调用父类的方法。


运行,于是诡异的一幕发生了。


修改实现后对象的内存状态

内存状态确实变化了。

但是一个没有被调用的方法是如何影响到对象的内存状态的呢!!!

难道遇到鬼了?我写了这么多年的代码,撞见鬼打墙了?为什么会存在一个这样的幽灵方法呢?

在随后的一两个小时里,我对此进行了反复测试,测试结果仿佛指向了一个规律,对象的内存状态在告诉我,幽灵方法确实被调用了,而程序的外部输出又在告诉我另一个事实,幽灵方法并没有被调用。可是为什么呢?为什么程序会有内外两种表现?

身心俱疲的我陷入了绝境。

忽然,我注意到了内存状态中的一个展示项:TrueWeight。


TrueWeight是一个属性

TrueWeight是一个属性!!!

那一刻,我仿佛听见一个遥远的声音传来,真相只有一个!!!

在这个程序中,TrueWeight属性并不是对trueWeight的简单封装,他还有一些额外的逻辑:

    public double TrueWeight {
            get {
                if (!isSet) {
                    if (nextWeight1 != null) {
                        setValue(nextWeight1.TrueWeight);
                    } else if (nextWeight2 != null) {
                        setValue(nextWeight2.TrueWeight);
                    }
                    setValue(infinitesimal);
                }
                return trueWeight;
            }
        }

我想,在C#编程实践中,在对属性的访问时,会执行一些附加的逻辑这种做法应该是相当普通的现象。而当我在查看对象的内存状态时,IDE同时也把对象附带的属性也显示出来。那么当IDE去访问属性时,会不会也触发了这些逻辑呢?

为了验证的我想法,我编写了一个简单的程序。

    public class TestClass {

        public int v = 0;
        bool isSet = false;

        public int TestPropety {
            get {
                if (!isSet) {
                    isSet = true;
                    setValue(1);
                }
                return v;
            }
        }

        void setValue(int i) {
            Console.WriteLine($"setValu({i})");
            v = i;
        }

        public static void Main() {
            TestClass test = new TestClass();
            Console.WriteLine($"value = {test.v}");
        }
    }

直接运行该程序的结果是这样的:

随后,我给程序打了断点:

运行,程序如预料之中的那样停在了Main方法体内的断点处,此时,我查看了一下test对象的内存状态:

setValue方法体内的断点没有触发,好像什么都没有发生一样。但v的值确实发生了变化。

我放开断点,继续运行,程序的输出如下:

我看到了setValue方法内的输出。

现在程序究竟发生了什么已经昭然若揭了。

在测试程序的自然运行过程中,setValue方法确实没有被执行,因此相关的输出是不可见的。但当我在程序运行过程中去查看对象的内存状态时,IDE会收集对象的字段和属性的值以供显示,而这一操作会触发属性的内部逻辑,从而导致对象的状态被修改,甚至影响到了程序的最终结果。换句话说,我的调试行为影响到了程序的行为。

在我的认知里,我一直认为C#的属性和Java的set/get方法是差不多的,无非是属性要更强大一些,能够做一些set/get方法做不到的事情。但现在看,属性有点儿强大过头,最起码,Java的任何IDE都不会在你查看内存状态的时候,把set/get方法的返回值也一并显示出来,并牵一发而动全身地做了一些你意想不到的事情。当然,事实上,问题不在于C#的属性设计得有问题,至少在程序自然运行状态下,一切都是自然,妥帖的。存在问题的是IDE的行为,在明知道收集属性的值会触发属性中包含的逻辑的情况下,还这么做,不是傻就是坏。

这种结果带有巨大的迷惑性,出现问题的地方和导致问题的地方相距甚远,而且无声无息,说不好哪天就会因此而栽跟头而毫不知情。你可能会疑惑,测试程序中的属性输出明明可以看见,为什么我之前却说没有看见?但那是在已知调试行为会影响程序运行的前提下,我才能够看见,换言之,我必须在查看了对象的内存状态之后再去查看输出才行,如果没有这个意识,或者没有依据这个顺序,都是无法看到输出的。而且,大多数情况下,我们都不会在访问属性时输出信息,也就意味着,即便出现问题,我们基本是无从得知的。这个情况要是再和程序中存在的错误逻辑叠加在一起,后果绝对是灾难性的,如果我们不知道我们调试的本身可能会影响到程序的行为,我们可能永远都搞不清楚问题到底出在哪里。

如果IDE坚持这么做的话, 那么我对大家的建议是,尽量不要在属性中附带可能修改对象内存状态的逻辑,或者如非必要,尽可能使用set/get方法来替代属性。但如果我们这么做,属性的价值又何在呢?鸡肋吗?

最后,我的程序并没有bug,真是瞎耽误工夫~

推荐阅读更多精彩内容

  • pdf下载地址:Java面试宝典 第一章内容介绍 20 第二章JavaSE基础 21 一、Java面向对象 21 ...
    王震阳阅读 78,774评论 25 511
  • 1.ios高性能编程 (1).内层 最小的内层平均值和峰值(2).耗电量 高效的算法和数据结构(3).初始化时...
    欧辰_OSR阅读 12,991评论 7 168
  • Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 4,476评论 1 16
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 128,783评论 19 550
  • 有些人,可能很大一部分人(包括自己),茌渴望成长的旅途上,都走过这样的弯路:买了很多书,也读了很多书;订了很多课程...
    _德成阅读 25评论 1 1