9.7 KiB

Raw Blame History Unescape Escape

Rust所有权转移时发生了奇怪的深拷贝

深拷贝可以说是Rust性能优化的禁忌之词，但是在最不该发生深拷贝的地方却发生了, 本文带领大家来深入分析下原因。

在所有权章节中，我们详细介绍过所有权转移(move), 里面提到过一个重点：当类型实现Copy特征时，不会转移所有权，而是直接对值进行拷贝：

fn main() {
    let x = 1;
    let y = x;
    // 不会报错
    println!("我(x)的值仅仅是被复制了，我还拥有值的所有权，不信你看：{:?}",x);

    let s = "aaa".to_string();
    let s1 = s;
    // 会报错
    println!("我(s)的值被转移给了s1，我已经失去所有权了: {}",s);
}

这里的x是数值类型，因此实现了Copy特征，当赋值给y时，仅仅是复制了值，并没有把所有权转移给y，但是s恰好相反，它没有实现Copy特征，当赋值后，所有权被转移给s1，最终导致了最后一行代码的报错.

根据之前的所有权学习章节，所有权转移时的仅仅是复制一个引用，并不会复制底层的数据，例如上面代码中，s的所有权转移给s1时，仅仅是复制了一个引用，该引用继续指向之前的字符串底层数据，因此所有权转移的性能是非常高的。

但是如果一切都这么完美，也不会出现这篇文章了，实际上是怎么样？先来看一段代码.

move时发生了数据的深拷贝

struct LargeArray {
    a: [i128; 10000],
}

impl LargeArray {
    #[inline(always)]
    fn transfer(mut self) -> Self {
        println!("{:?}", &mut self.a[1] as *mut i128);

        // 改变数组中的值
        self.a[1] += 23;
        self.a[4] += 24;

        // 返回所有权
        self
    }
}

fn main() {
    let mut f = LargeArray { a: [10i128; 10000] };

    println!("{:?}", &mut f.a[1] as *mut i128);

    let mut f2 = f.transfer();

    println!("{:?}", &mut f2.a[1] as *mut i128);
}

上面的例子很简单，创建了一个结构体f(内部有一个大数组)，接着将它的所有权转移给transfer方法，最后再通过Self返回，转移给f2，在此过程中，观察结构体中的数组第二个元素的内存地址如何变化。

这里还有几个注意点：

LargeArray没有实现Copy特征，因此在所有权转移时， 本应该只是复制一下引用，底层的数组并不会被复制
transfer方法的参数self表示接收所有权，而不是借用，返回类型Self也表示返回所有权，而不是返回借用, 具体内容在方法章节有介绍

从上可知，我们并不应该去复制底层的数组，那么底层数组的地址也不应该变化，换而言之三次内存地址输出应该是同一个地址。但是真的如此吗？世事难料：

0x16f9d6870
0x16fa4bbc0
0x16fa24ac0

果然，结果让人大跌眼镜，竟然三次地址都不一样，意味着每次转移所有权都发生了底层数组的深拷贝！什么情况？！！如果这样，我们以后还能信任Rust吗？完全不符合官方的宣传。

在福建有一个武夷山5A景区，不仅美食特别好吃，而且风景非常优美，其中最著名的就是历时1个多小时的九曲十八弯漂流，而我们的结论是否也能像漂游一样来个大转折？大家拭目以待。

罪魁祸首println?

首先，通过谷歌搜索，我发现了一些蛛丝马迹，有文章提到如果通过println输出内存地址，可能会导致编译器优化失效，也就是从本该有的所有权转移变成了深拷贝，不妨来试试。

但是问题又来了，如果不用println或者类似的方法，我们怎么观察内存地址？好像陷入了绝路。。。只能从Rust之外去想办法了，此时大学学过的汇编发挥了作用：

.LCPI0_0:
        .quad   10
        .quad   0
example::xxx:
        mov     eax, 160000
        call    __rust_probestack
        sub     rsp, rax
        mov     rax, rsp
        lea     rcx, [rsp + 160000]
        vbroadcasti128  ymm0, xmmword ptr [rip + .LCPI0_0]
.LBB0_1:
        vmovdqu ymmword ptr [rax], ymm0
        vmovdqu ymmword ptr [rax + 32], ymm0
        vmovdqu ymmword ptr [rax + 64], ymm0
        vmovdqu ymmword ptr [rax + 96], ymm0
        vmovdqu ymmword ptr [rax + 128], ymm0
        vmovdqu ymmword ptr [rax + 160], ymm0
        vmovdqu ymmword ptr [rax + 192], ymm0
        vmovdqu ymmword ptr [rax + 224], ymm0
        vmovdqu ymmword ptr [rax + 256], ymm0
        vmovdqu ymmword ptr [rax + 288], ymm0
        vmovdqu ymmword ptr [rax + 320], ymm0
        vmovdqu ymmword ptr [rax + 352], ymm0
        vmovdqu ymmword ptr [rax + 384], ymm0
        vmovdqu ymmword ptr [rax + 416], ymm0
        vmovdqu ymmword ptr [rax + 448], ymm0
        vmovdqu ymmword ptr [rax + 480], ymm0
        vmovdqu ymmword ptr [rax + 512], ymm0
        vmovdqu ymmword ptr [rax + 544], ymm0
        vmovdqu ymmword ptr [rax + 576], ymm0
        vmovdqu ymmword ptr [rax + 608], ymm0
        add     rax, 640
        cmp     rax, rcx
        jne     .LBB0_1
        mov     rax, qword ptr [rsp + 16]
        mov     rdx, qword ptr [rsp + 24]
        add     rax, 69
        adc     rdx, 0
        add     rsp, 160000
        vzeroupper
        ret

去掉所有println后的汇编生成如上所示(大家可以在godbolt上自己尝试)，以我蹩脚的汇编水平来看，貌似没有任何数组拷贝的发生，也就是说：如同量子的不可观测性，我们的move也这么傲娇？我们用println观测，它就傲娇去复制，不观测时，就老老实实转移所有权？WTF!

事情感觉进入了僵局，下一步该如何办？

栈和堆的不同move行为

我突然灵光一现，想到一个问题，之前的所有权转移其实可以分为两类：栈上数据的复制和堆上数据的转移，这也是非常符合直觉的，例如i32这种类型实现了Copy特征，可以存储在栈上，因此它就是复制行为，而String类型是引用存储在栈上，底层数据存储在堆上，因此转移所有权时只需要复制一下引用即可。

那问题来了，我们的LargeArray存在哪里？这也许就是一个破局点！

struct LargeArray {
    a: [i128; 10000],
}

结构体是一个复合类型，它内部字段的数据存在哪里，就大致决定了它存在哪里。而该结构体里面的a字段是一个数组，而不是动态数组Vec，从数组章节可知：数组是存储在栈上的数据结构！

再想想，栈上的数据在move的时候，是要从一个栈复制到另外一个栈的，那是不是内存地址就变了？！因此，就能完美解释，为什么使用println时，数组的地址会变化了，是因为栈上的数组发生了复制。

但是问题还有，为什么不使用println，数组地址就不变？要解释清楚这个问题，先从编译器优化讲起。

编译器对move的优化

从根本上来说，move就意味着拷贝复制，只不过看是浅拷贝还是深拷贝，对于堆上的数据来说，浅拷贝只复制引用，而栈上的数据则是整个复制。

但是在实际场景中，由于编译器的复杂实现，它能优化的场景远比我们想象中更多，例如对于move过程中的复制，编译器有可能帮你优化掉，在没有println的代码中，该move过程就被Rust编译器优化了。

但是这种编译器优化非常复杂，而且随着Rust的版本更新在不停变化，因此几乎没有人能说清楚这里面的门门道道，但是有一点可以知道：move确实存在被优化的可能性，最终避免了复制的发生.

那么println没有被优化的原因也呼之欲出了: 它阻止了编译器对move的优化。

println阻止了优化

编译器优化的一个基本准则就是：中间过程没有其它代码在使用，则可以尝试消除这些中间过程。

回头来看看println:

println!("{:?}", &mut f.a[1] as *mut i128);

它需要打印数组在各个点的内存地址，假如编译器优化了复制，那这些中间状态的内存地址是不是就丢失了？对于这种可能会导致状态丢失的情况，编译器是不可能进行优化的，因此move时的栈上数组复制就顺理成章的发生了, 还是2次。

最佳实践

那么，在实践中遇到这种情况怎么办？

&mut self

其实办法也很多，首当其冲的就是使用&mut self进行可变借用，而不是转移进来所有权，再转移出去。

Box分配到堆上

如果你确实需要依赖所有权的转移来实现某个功能(例如链式方法调用:x.a().b()...)，那么就需要使用Box把该数组分配在堆上，而不是栈上：

struct LargeArray {
    a: Box<[i128; 10000]>,
}

impl LargeArray {
    #[inline(always)]
    fn transfer(mut self) -> Self {
        println!("{:?}", &mut self.a[1] as *mut i128);

        //do some stuff to alter it
        self.a[1] += 23;
        self.a[4] += 24;

        //return the same object
        self
    }
}

fn main() {
    let mut f = LargeArray { a: Box::new([10i128; 10000] )};

    println!("{:?}", &mut f.a[1] as *mut i128);

    let mut f2 = f.transfer();

    println!("{:?}", &mut f2.a[1] as *mut i128);
}

输出如下:

0x138008010
0x138008010
0x138008010

完美符合了我们对堆上数据的预期，hooray!

神龟莫测的编译器优化

当然，你也可以选择相信编译器的优化，虽然很难识它真面目，同时它的行为也神鬼莫测，但是总归是在之前的例子中证明了，它确实可以，不是嘛？ = , =

9.7 KiB Raw Blame History Unescape Escape