Rust 不允许这种代码，因为它是不安全的：
fn main() {
let mut i = 42;
let ref_to_i_1 = unsafe { &mut *(&mut i as *mut i32) };
let ref_to_i_2 = unsafe { &mut *(&mut i as *mut i32) };
*ref_to_i_1 = 1;
*ref_to_i_2 = 2;
}
我如何通过对同一事物使用多个可变引用来做一些坏事情（例如分段错误、未定义行为等）？
我唯一能想到的可能问题来自数据的生命周期。如果i仍然存在，那么每个可变引用都应该没问题。
我可以看出当引入线程时可能会出现问题，但是如果我在一个线程中执行所有操作，为什么仍然会被阻止呢？
在C++程序中，甚至在Java程序中，一个非常常见的陷阱是在迭代过程中修改集合，例如：
for (it: collection) {
if (predicate(*it)) {
collection.remove(it);
}
}
对于C++标准库集合，这会导致未定义的行为。也许迭代会一直工作，直到您到达最后一个条目，但是最后一个条目将解引用悬空指针或超出数组范围。可能支撑集合的整个数组将被重新定位，并且它将立即失败。也许它大多数时间都有效，但如果在错误的时间重新分配，则会失败。对于Java标准集合中的大多数，根据语言规范，这也是未定义的行为，但集合往往会抛出ConcurrentModificationException——这会导致运行时成本，即使您的代码是正确的。两种语言都无法在编译期间检测到此错误。
这是并发造成的数据竞争的常见示例，即使在单线程环境下也是如此。并发不仅意味着并行性：它还可以意味着嵌套计算。在Rust中，编译期间会检测到这种错误，因为迭代器对集合具有不可变借用，因此在迭代器存活时不能更改集合。
一个更易理解但较少见的示例是当您向函数传递多个指针（或引用）时出现指针别名。一个具体的示例是将重叠的内存范围传递给memcpy而不是memmove。实际上，Rust的memcpy等价函数也是unsafe的，但这是因为它接受指针而不是引用。链接的页面展示了如何使用可变引用从而产生安全的swap函数。
一个更牵强的引用别名的例子如下：
int f(int *x, int *y) { return (*x)++ + (*y)++; }
int i = 3;
f(&i, &i); // result is undefined
在Rust中，您不能编写像这样的函数调用，因为您必须获取同一变量的两个可变借用。
&mut引用实际上并没有使用noalias标志，所以从实际角度讲���你现在可能无法通过这种方式触发未定义行为。你所触发的是"实现特定行为"，它是"按照LLVM的C++行为"执行。a; b; c;
如果（根据编译器的知识）没有逻辑原因要求语句必须以特定的原子序列执行，那么不能保证编译器在运行时按照这个顺序执行它们。上面链接的博客的第三部分演示了这如何导致未定义的行为。
tl;dr：基本上，编译器可能会执行各种优化；只有你的程序不触发未定义的行为，这些优化才能保证使你的程序行为具有确定性。
据我所知，Rust编译器目前没有使用许多可能导致此类失败的“高级优化”，但不能保证它将来不会使用。引入新的编译器优化并不是一项“破坏性变更”。
因此...实际上，现在通过可变别名触发实际的未定义行为的可能性非常小；但是限制允许未来进行性能优化。
相关引用：
C FAQ将“未定义行为”定义为：
任何事情都可能发生；标准不强制任何要求。程序可能无法编译，或者执行不正确（崩溃或默默生成不正确的结果），或者幸运地恰好做到程序员想要的。
作者注：以下答案最初是为如何交织的作用域创建“数据竞争”？撰写的。
编译器允许在假定&mut指针是排他（不具别名）的情况下优化它们。你的代码打破了这个假设。
问题中的示例太过简单，无法展示任何有趣的错误行为，但考虑将 ref_to_i_1 和 ref_to_i_2 传递给修改两者并然后执行某些操作的函数：
fn main() {
let mut i = 42;
let ref_to_i_1 = unsafe { &mut *(&mut i as *mut i32) };
let ref_to_i_2 = unsafe { &mut *(&mut i as *mut i32) };
foo(ref_to_i_1, ref_to_i_2);
}
fn foo(r1: &mut i32, r2: &mut i32) {
*r1 = 1;
*r2 = 2;
println!("{}", r1);
println!("{}", r2);
}
r1和r2，因为它们不允许别名。// The following is an illustration of how the compiler might rearrange
// side effects in a function to optimize it. Optimization passes in the
// compiler actually work on (MIR and) LLVM IR, not on raw Rust code.
fn foo(r1: &mut i32, r2: &mut i32) {
*r1 = 1;
println!("{}", r1);
*r2 = 2;
println!("{}", r2);
}
它甚至可能会意识到println！总是打印相同的值，并利用这一事实进一步重新排列foo：
fn foo(r1: &mut i32, r2: &mut i32) {
println!("{}", 1);
println!("{}", 2);
*r1 = 1;
*r2 = 2;
}
r1和r2别名而不违反规则†，这就使得这种优化是有效的。&mut 引用的属性，这样编译器就可以对一个代码段进行轻微的优化，而不需要理解所有代码。&mut 别名规则就等于请它替你完成工作。&mut。在这个示例中，你可以像注释中提到的那样使用&Cell<i32>而不是&mut i32。fn main() {
let mut i = std::cell::Cell::new(42);
let ref_to_i_1 = &i;
let ref_to_i_2 = &i;
foo(ref_to_i_1, ref_to_i_2);
}
fn foo(r1: &Cell<i32>, r2: &Cell<i32>) {
r1.set(1);
r2.set(2);
println!("{}", r1.get()); // prints 2, guaranteed
println!("{}", r2.get()); // also prints 2
}
std::cell中的类型提供了"内部可变性"，这是术语，表示"不允许某些优化，因为&引用可能会改变事物状态"。它们并不总是像使用&mut那样方便，但这是因为使用它们会给你更多的灵活性来编写以上代码。
† 请注意，仅使用unsafe本身并不算"违反规则"。为了让您的代码具有定义的行为，即使在使用unsafe时，&mut引用也不能被别名所引用。
push到已被借用的Vec中：let mut v = vec!['a'];
let c = &v[0];
v.push('b');
dbg!(c);
这是一个编译器错误：
error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
--> src/main.rs:4:5
|
3 | let c = &v[0];
| - immutable borrow occurs here
4 | v.push('b');
| ^^^^^^^^^^^ mutable borrow occurs here
5 | dbg!(c);
| - immutable borrow later used here
enum MyEnum<'a> {
Ptr(&'a i32),
Usize(usize),
}
let my_int = 42;
let mut my_enum = MyEnum::Ptr(&my_int);
let my_int_ptr_ptr: &&i32 = match &my_enum {
MyEnum::Ptr(i) => i,
MyEnum::Usize(_) => unreachable!(),
};
my_enum = MyEnum::Usize(0xdeadbeefdeadbeef);
dbg!(**my_int_ptr_ptr);
在这里，我们将指向my_int的指针存储在my_enum中，并使my_int_ptr_ptr指向my_enum。如果我们可以重新分配my_enum，那么我们可能会破坏my_int_ptr_ptr指向的位。对my_int_ptr_ptr进行双重解引用将是一个野指针读取，这可能会导致段错误。幸运的是，这是别名规则的另一种违反，它不会编译：
error[E0506]: cannot assign to `my_enum` because it is borrowed
--> src/main.rs:12:1
|
8 | let my_int_ptr_ptr: &&i32 = match &my_enum {
| -------- borrow of `my_enum` occurs here
...
12 | my_enum = MyEnum::Usize(0xdeadbeefdeadbeef);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ assignment to borrowed `my_enum` occurs here
13 | dbg!(**my_int_ptr_ptr);
| ---------------- borrow later used here
x引用的对象的内容，然后对由y引用的对象执行某些操作，再次读取由x引用的对象的内容，并且编译器知道对y的操作不可能已修改由x引用的对象，则编译器可以将对x的两次读取合并为一次读取。如果在引用的生命周期内对象永远不会被修改，使用该引用的机器代码就不必担心在该生命周期内哪些操作可能会改变它，因为任何操作都无法这样做。
如果在引用的生命周期内，对象只会被基于该引用的可见引用所修改，使用该引用的机器代码就不必担心使用该引用的任何操作是否会与涉及看似无关的引用的操作相互作用，因为没有看似无关的引用将标识相同的对象。
允许可变引用之间存在别名的可能性会使事情变得更加复杂，因为许多优化可以与对可变对象的非共享引用或对不可变对象的共享引用交替执行，但此时不能这样做。一旦语言支持涉及看似独立的引用的操作需要按精确顺序处理的情况，编译器很难知道何时需要进行这样的精确排序。
&Cell<T>，它与您想要的语义非常接近。这会排除一些编译器优化，不幸的是，编译器缺乏一些语法糖来方便地处理单元格。 - CodesInChaos