649 lines
50 KiB
HTML
649 lines
50 KiB
HTML
|
<!DOCTYPE HTML>
|
|||
|
<html lang="en" class="sidebar-visible no-js light">
|
|||
|
<head>
|
|||
|
<!-- Book generated using mdBook -->
|
|||
|
<meta charset="UTF-8">
|
|||
|
<title>Reference Cycles Can Leak Memory - The Rust Programming Language</title>
|
|||
|
|
|||
|
|
|||
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|||
|
<meta name="description" content="">
|
|||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|||
|
<meta name="theme-color" content="#ffffff" />
|
|||
|
|
|||
|
<link rel="shortcut icon" href="favicon.png">
|
|||
|
<link rel="stylesheet" href="css/variables.css">
|
|||
|
<link rel="stylesheet" href="css/general.css">
|
|||
|
<link rel="stylesheet" href="css/chrome.css">
|
|||
|
<link rel="stylesheet" href="css/print.css" media="print">
|
|||
|
|
|||
|
<!-- Fonts -->
|
|||
|
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
|
|||
|
<link href="googleFonts/css.css" rel="stylesheet" type="text/css">
|
|||
|
|
|||
|
<!-- Highlight.js Stylesheets -->
|
|||
|
<link rel="stylesheet" href="highlight.css">
|
|||
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|||
|
<link rel="stylesheet" href="ayu-highlight.css">
|
|||
|
|
|||
|
<!-- Custom theme stylesheets -->
|
|||
|
|
|||
|
<link rel="stylesheet" href="ferris.css">
|
|||
|
|
|||
|
<link rel="stylesheet" href="theme/2018-edition.css">
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<!-- Provide site root to javascript -->
|
|||
|
<script type="text/javascript">
|
|||
|
var path_to_root = "";
|
|||
|
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "light" : "light";
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|||
|
<script type="text/javascript">
|
|||
|
try {
|
|||
|
var theme = localStorage.getItem('mdbook-theme');
|
|||
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|||
|
|
|||
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|||
|
}
|
|||
|
|
|||
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|||
|
}
|
|||
|
} catch (e) { }
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|||
|
<script type="text/javascript">
|
|||
|
var theme;
|
|||
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|||
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|||
|
var html = document.querySelector('html');
|
|||
|
html.classList.remove('no-js')
|
|||
|
html.classList.remove('light')
|
|||
|
html.classList.add(theme);
|
|||
|
html.classList.add('js');
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|||
|
<script type="text/javascript">
|
|||
|
var html = document.querySelector('html');
|
|||
|
var sidebar = 'hidden';
|
|||
|
if (document.body.clientWidth >= 1080) {
|
|||
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|||
|
sidebar = sidebar || 'visible';
|
|||
|
}
|
|||
|
html.classList.remove('sidebar-visible');
|
|||
|
html.classList.add("sidebar-" + sidebar);
|
|||
|
</script>
|
|||
|
|
|||
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|||
|
<div id="sidebar-scrollbox" class="sidebar-scrollbox">
|
|||
|
<ol class="chapter"><li class="expanded affix "><a href="title-page.html">The Rust Programming Language</a></li><li class="expanded affix "><a href="foreword.html">Foreword</a></li><li class="expanded affix "><a href="ch00-00-introduction.html">Introduction</a></li><li class="expanded "><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li class="expanded "><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li class="expanded "><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li class="expanded "><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li class="expanded "><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li class="expanded "><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li class="expanded "><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li class="expanded "><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li class="expanded "><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> Functions</a></li><li class="expanded "><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li class="expanded "><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li class="expanded "><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li class="expanded "><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li class="expanded "><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References and Borrowing</a></li><li class="expanded "><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> The Slice Type</a></li></ol></li><li class="expanded "><a href="ch05-00-structs.html"><strong aria-hidden="true">5.</strong> Using Structs to Structure Related Data</a></li><li><ol class="section"><li class="expanded "><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li class="expanded "><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li class="expanded "><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li class="expanded "><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li class="expanded "><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li class="expanded "><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li class="expanded "><a href="ch06-03-if-let.html"><strong aria-hidden="true">6.3.</strong> Concise Control Flow with if let</a></li></ol></li><li class="expanded "><a href="ch07-00-managing-growing-projects-with-packages-crates-and-modules.html"><strong aria-hidden="true">7.</strong> Managing Growing Projects with Packages, Crates, and Modules</a></li><li><ol class="section"><li class="expanded "><a href="ch07-01-packages-and-crates.html"><strong aria-hidden="true">7.1.</strong> Packages and Crates</a></li><li class="expanded "><a href="ch07-02-defining-modules-to-control-scope-and-privacy.html"><strong aria-hidden="true">7.2.</strong> Defining Modules to Control Scope and Privacy</a></li><li class="expanded "><a href="ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html"><
|
|||
|
</div>
|
|||
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
|||
|
</nav>
|
|||
|
|
|||
|
<div id="page-wrapper" class="page-wrapper">
|
|||
|
|
|||
|
<div class="page">
|
|||
|
|
|||
|
<div id="menu-bar" class="menu-bar">
|
|||
|
<div id="menu-bar-sticky-container">
|
|||
|
<div class="left-buttons">
|
|||
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|||
|
<i class="fa fa-bars"></i>
|
|||
|
</button>
|
|||
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|||
|
<i class="fa fa-paint-brush"></i>
|
|||
|
</button>
|
|||
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|||
|
</ul>
|
|||
|
|
|||
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|||
|
<i class="fa fa-search"></i>
|
|||
|
</button>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
<h1 class="menu-title">The Rust Programming Language</h1>
|
|||
|
|
|||
|
<div class="right-buttons">
|
|||
|
<a href="print.html" title="Print this book" aria-label="Print this book">
|
|||
|
<i id="print-button" class="fa fa-print"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<div id="search-wrapper" class="hidden">
|
|||
|
<form id="searchbar-outer" class="searchbar-outer">
|
|||
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|||
|
</form>
|
|||
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|||
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|||
|
<ul id="searchresults">
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|||
|
<script type="text/javascript">
|
|||
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|||
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|||
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|||
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|||
|
});
|
|||
|
</script>
|
|||
|
|
|||
|
<div id="content" class="content">
|
|||
|
<main>
|
|||
|
<h2><a class="header" href="#reference-cycles-can-leak-memory" id="reference-cycles-can-leak-memory">Reference Cycles Can Leak Memory</a></h2>
|
|||
|
<p>Rust’s memory safety guarantees make it difficult, but not impossible, to
|
|||
|
accidentally create memory that is never cleaned up (known as a <em>memory leak</em>).
|
|||
|
Preventing memory leaks entirely is not one of Rust’s guarantees in the same
|
|||
|
way that disallowing data races at compile time is, meaning memory leaks are
|
|||
|
memory safe in Rust. We can see that Rust allows memory leaks by using <code>Rc<T></code>
|
|||
|
and <code>RefCell<T></code>: it’s possible to create references where items refer to each
|
|||
|
other in a cycle. This creates memory leaks because the reference count of each
|
|||
|
item in the cycle will never reach 0, and the values will never be dropped.</p>
|
|||
|
<h3><a class="header" href="#creating-a-reference-cycle" id="creating-a-reference-cycle">Creating a Reference Cycle</a></h3>
|
|||
|
<p>Let’s look at how a reference cycle might happen and how to prevent it,
|
|||
|
starting with the definition of the <code>List</code> enum and a <code>tail</code> method in Listing
|
|||
|
15-25:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<!-- Hidden fn main is here to disable the automatic wrapping in fn main that
|
|||
|
doc tests do; the `use List` fails if this listing is put within a main -->
|
|||
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">fn main() {}
|
|||
|
</span>use std::rc::Rc;
|
|||
|
use std::cell::RefCell;
|
|||
|
use crate::List::{Cons, Nil};
|
|||
|
|
|||
|
#[derive(Debug)]
|
|||
|
enum List {
|
|||
|
Cons(i32, RefCell<Rc<List>>),
|
|||
|
Nil,
|
|||
|
}
|
|||
|
|
|||
|
impl List {
|
|||
|
fn tail(&self) -> Option<&RefCell<Rc<List>>> {
|
|||
|
match self {
|
|||
|
Cons(_, item) => Some(item),
|
|||
|
Nil => None,
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
</code></pre></pre>
|
|||
|
<p><span class="caption">Listing 15-25: A cons list definition that holds a
|
|||
|
<code>RefCell<T></code> so we can modify what a <code>Cons</code> variant is referring to</span></p>
|
|||
|
<p>We’re using another variation of the <code>List</code> definition from Listing 15-5. The
|
|||
|
second element in the <code>Cons</code> variant is now <code>RefCell<Rc<List>></code>, meaning that
|
|||
|
instead of having the ability to modify the <code>i32</code> value as we did in Listing
|
|||
|
15-24, we want to modify which <code>List</code> value a <code>Cons</code> variant is pointing to.
|
|||
|
We’re also adding a <code>tail</code> method to make it convenient for us to access the
|
|||
|
second item if we have a <code>Cons</code> variant.</p>
|
|||
|
<p>In Listing 15-26, we’re adding a <code>main</code> function that uses the definitions in
|
|||
|
Listing 15-25. This code creates a list in <code>a</code> and a list in <code>b</code> that points to
|
|||
|
the list in <code>a</code>. Then it modifies the list in <code>a</code> to point to <code>b</code>, creating a
|
|||
|
reference cycle. There are <code>println!</code> statements along the way to show what the
|
|||
|
reference counts are at various points in this process.</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">use crate::List::{Cons, Nil};
|
|||
|
</span><span class="boring">use std::rc::Rc;
|
|||
|
</span><span class="boring">use std::cell::RefCell;
|
|||
|
</span><span class="boring">#[derive(Debug)]
|
|||
|
</span><span class="boring">enum List {
|
|||
|
</span><span class="boring"> Cons(i32, RefCell<Rc<List>>),
|
|||
|
</span><span class="boring"> Nil,
|
|||
|
</span><span class="boring">}
|
|||
|
</span><span class="boring">
|
|||
|
</span><span class="boring">impl List {
|
|||
|
</span><span class="boring"> fn tail(&self) -> Option<&RefCell<Rc<List>>> {
|
|||
|
</span><span class="boring"> match self {
|
|||
|
</span><span class="boring"> Cons(_, item) => Some(item),
|
|||
|
</span><span class="boring"> Nil => None,
|
|||
|
</span><span class="boring"> }
|
|||
|
</span><span class="boring"> }
|
|||
|
</span><span class="boring">}
|
|||
|
</span><span class="boring">
|
|||
|
</span>fn main() {
|
|||
|
let a = Rc::new(Cons(5, RefCell::new(Rc::new(Nil))));
|
|||
|
|
|||
|
println!("a initial rc count = {}", Rc::strong_count(&a));
|
|||
|
println!("a next item = {:?}", a.tail());
|
|||
|
|
|||
|
let b = Rc::new(Cons(10, RefCell::new(Rc::clone(&a))));
|
|||
|
|
|||
|
println!("a rc count after b creation = {}", Rc::strong_count(&a));
|
|||
|
println!("b initial rc count = {}", Rc::strong_count(&b));
|
|||
|
println!("b next item = {:?}", b.tail());
|
|||
|
|
|||
|
if let Some(link) = a.tail() {
|
|||
|
*link.borrow_mut() = Rc::clone(&b);
|
|||
|
}
|
|||
|
|
|||
|
println!("b rc count after changing a = {}", Rc::strong_count(&b));
|
|||
|
println!("a rc count after changing a = {}", Rc::strong_count(&a));
|
|||
|
|
|||
|
// Uncomment the next line to see that we have a cycle;
|
|||
|
// it will overflow the stack
|
|||
|
// println!("a next item = {:?}", a.tail());
|
|||
|
}
|
|||
|
</code></pre></pre>
|
|||
|
<p><span class="caption">Listing 15-26: Creating a reference cycle of two <code>List</code>
|
|||
|
values pointing to each other</span></p>
|
|||
|
<p>We create an <code>Rc<List></code> instance holding a <code>List</code> value in the variable <code>a</code>
|
|||
|
with an initial list of <code>5, Nil</code>. We then create an <code>Rc<List></code> instance
|
|||
|
holding another <code>List</code> value in the variable <code>b</code> that contains the value 10 and
|
|||
|
points to the list in <code>a</code>.</p>
|
|||
|
<p>We modify <code>a</code> so it points to <code>b</code> instead of <code>Nil</code>, creating a cycle. We
|
|||
|
do that by using the <code>tail</code> method to get a reference to the
|
|||
|
<code>RefCell<Rc<List>></code> in <code>a</code>, which we put in the variable <code>link</code>. Then we use
|
|||
|
the <code>borrow_mut</code> method on the <code>RefCell<Rc<List>></code> to change the value inside
|
|||
|
from an <code>Rc<List></code> that holds a <code>Nil</code> value to the <code>Rc<List></code> in <code>b</code>.</p>
|
|||
|
<p>When we run this code, keeping the last <code>println!</code> commented out for the
|
|||
|
moment, we’ll get this output:</p>
|
|||
|
<pre><code class="language-text">a initial rc count = 1
|
|||
|
a next item = Some(RefCell { value: Nil })
|
|||
|
a rc count after b creation = 2
|
|||
|
b initial rc count = 1
|
|||
|
b next item = Some(RefCell { value: Cons(5, RefCell { value: Nil }) })
|
|||
|
b rc count after changing a = 2
|
|||
|
a rc count after changing a = 2
|
|||
|
</code></pre>
|
|||
|
<p>The reference count of the <code>Rc<List></code> instances in both <code>a</code> and <code>b</code> are 2
|
|||
|
after we change the list in <code>a</code> to point to <code>b</code>. At the end of <code>main</code>, Rust
|
|||
|
will try to drop <code>b</code> first, which will decrease the count of the <code>Rc<List></code>
|
|||
|
instance in <code>b</code> by 1.</p>
|
|||
|
<p>However, because <code>a</code> is still referencing the <code>Rc<List></code> that was in <code>b</code>, that
|
|||
|
<code>Rc<List></code> has a count of 1 rather than 0, so the memory the <code>Rc<List></code> has on
|
|||
|
the heap won’t be dropped. The memory will just sit there with a count of 1,
|
|||
|
forever. To visualize this reference cycle, we’ve created a diagram in Figure
|
|||
|
15-4.</p>
|
|||
|
<img alt="Reference cycle of lists" src="img/trpl15-04.svg" class="center" />
|
|||
|
<p><span class="caption">Figure 15-4: A reference cycle of lists <code>a</code> and <code>b</code>
|
|||
|
pointing to each other</span></p>
|
|||
|
<p>If you uncomment the last <code>println!</code> and run the program, Rust will try to
|
|||
|
print this cycle with <code>a</code> pointing to <code>b</code> pointing to <code>a</code> and so forth until it
|
|||
|
overflows the stack.</p>
|
|||
|
<p>In this case, right after we create the reference cycle, the program ends. The
|
|||
|
consequences of this cycle aren’t very dire. However, if a more complex program
|
|||
|
allocated lots of memory in a cycle and held onto it for a long time, the
|
|||
|
program would use more memory than it needed and might overwhelm the system,
|
|||
|
causing it to run out of available memory.</p>
|
|||
|
<p>Creating reference cycles is not easily done, but it’s not impossible either.
|
|||
|
If you have <code>RefCell<T></code> values that contain <code>Rc<T></code> values or similar nested
|
|||
|
combinations of types with interior mutability and reference counting, you must
|
|||
|
ensure that you don’t create cycles; you can’t rely on Rust to catch them.
|
|||
|
Creating a reference cycle would be a logic bug in your program that you should
|
|||
|
use automated tests, code reviews, and other software development practices to
|
|||
|
minimize.</p>
|
|||
|
<p>Another solution for avoiding reference cycles is reorganizing your data
|
|||
|
structures so that some references express ownership and some references don’t.
|
|||
|
As a result, you can have cycles made up of some ownership relationships and
|
|||
|
some non-ownership relationships, and only the ownership relationships affect
|
|||
|
whether or not a value can be dropped. In Listing 15-25, we always want <code>Cons</code>
|
|||
|
variants to own their list, so reorganizing the data structure isn’t possible.
|
|||
|
Let’s look at an example using graphs made up of parent nodes and child nodes
|
|||
|
to see when non-ownership relationships are an appropriate way to prevent
|
|||
|
reference cycles.</p>
|
|||
|
<h3><a class="header" href="#preventing-reference-cycles-turning-an-rct-into-a-weakt" id="preventing-reference-cycles-turning-an-rct-into-a-weakt">Preventing Reference Cycles: Turning an <code>Rc<T></code> into a <code>Weak<T></code></a></h3>
|
|||
|
<p>So far, we’ve demonstrated that calling <code>Rc::clone</code> increases the
|
|||
|
<code>strong_count</code> of an <code>Rc<T></code> instance, and an <code>Rc<T></code> instance is only cleaned
|
|||
|
up if its <code>strong_count</code> is 0. You can also create a <em>weak reference</em> to the
|
|||
|
value within an <code>Rc<T></code> instance by calling <code>Rc::downgrade</code> and passing a
|
|||
|
reference to the <code>Rc<T></code>. When you call <code>Rc::downgrade</code>, you get a smart
|
|||
|
pointer of type <code>Weak<T></code>. Instead of increasing the <code>strong_count</code> in the
|
|||
|
<code>Rc<T></code> instance by 1, calling <code>Rc::downgrade</code> increases the <code>weak_count</code> by 1.
|
|||
|
The <code>Rc<T></code> type uses <code>weak_count</code> to keep track of how many <code>Weak<T></code>
|
|||
|
references exist, similar to <code>strong_count</code>. The difference is the <code>weak_count</code>
|
|||
|
doesn’t need to be 0 for the <code>Rc<T></code> instance to be cleaned up.</p>
|
|||
|
<p>Strong references are how you can share ownership of an <code>Rc<T></code> instance. Weak
|
|||
|
references don’t express an ownership relationship. They won’t cause a
|
|||
|
reference cycle because any cycle involving some weak references will be broken
|
|||
|
once the strong reference count of values involved is 0.</p>
|
|||
|
<p>Because the value that <code>Weak<T></code> references might have been dropped, to do
|
|||
|
anything with the value that a <code>Weak<T></code> is pointing to, you must make sure the
|
|||
|
value still exists. Do this by calling the <code>upgrade</code> method on a <code>Weak<T></code>
|
|||
|
instance, which will return an <code>Option<Rc<T>></code>. You’ll get a result of <code>Some</code>
|
|||
|
if the <code>Rc<T></code> value has not been dropped yet and a result of <code>None</code> if the
|
|||
|
<code>Rc<T></code> value has been dropped. Because <code>upgrade</code> returns an <code>Option<T></code>, Rust
|
|||
|
will ensure that the <code>Some</code> case and the <code>None</code> case are handled, and there
|
|||
|
won’t be an invalid pointer.</p>
|
|||
|
<p>As an example, rather than using a list whose items know only about the next
|
|||
|
item, we’ll create a tree whose items know about their children items <em>and</em>
|
|||
|
their parent items.</p>
|
|||
|
<h4><a class="header" href="#creating-a-tree-data-structure-a-node-with-child-nodes" id="creating-a-tree-data-structure-a-node-with-child-nodes">Creating a Tree Data Structure: a <code>Node</code> with Child Nodes</a></h4>
|
|||
|
<p>To start, we’ll build a tree with nodes that know about their child nodes.
|
|||
|
We’ll create a struct named <code>Node</code> that holds its own <code>i32</code> value as well as
|
|||
|
references to its children <code>Node</code> values:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust">
|
|||
|
<span class="boring">#![allow(unused_variables)]
|
|||
|
</span><span class="boring">fn main() {
|
|||
|
</span>use std::rc::Rc;
|
|||
|
use std::cell::RefCell;
|
|||
|
|
|||
|
#[derive(Debug)]
|
|||
|
struct Node {
|
|||
|
value: i32,
|
|||
|
children: RefCell<Vec<Rc<Node>>>,
|
|||
|
}
|
|||
|
<span class="boring">}
|
|||
|
</span></code></pre></pre>
|
|||
|
<p>We want a <code>Node</code> to own its children, and we want to share that ownership with
|
|||
|
variables so we can access each <code>Node</code> in the tree directly. To do this, we
|
|||
|
define the <code>Vec<T></code> items to be values of type <code>Rc<Node></code>. We also want to
|
|||
|
modify which nodes are children of another node, so we have a <code>RefCell<T></code> in
|
|||
|
<code>children</code> around the <code>Vec<Rc<Node>></code>.</p>
|
|||
|
<p>Next, we’ll use our struct definition and create one <code>Node</code> instance named
|
|||
|
<code>leaf</code> with the value 3 and no children, and another instance named <code>branch</code>
|
|||
|
with the value 5 and <code>leaf</code> as one of its children, as shown in Listing 15-27:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">use std::rc::Rc;
|
|||
|
</span><span class="boring">use std::cell::RefCell;
|
|||
|
</span><span class="boring">
|
|||
|
</span><span class="boring">#[derive(Debug)]
|
|||
|
</span><span class="boring">struct Node {
|
|||
|
</span><span class="boring"> value: i32,
|
|||
|
</span><span class="boring"> children: RefCell<Vec<Rc<Node>>>,
|
|||
|
</span><span class="boring">}
|
|||
|
</span><span class="boring">
|
|||
|
</span>fn main() {
|
|||
|
let leaf = Rc::new(Node {
|
|||
|
value: 3,
|
|||
|
children: RefCell::new(vec![]),
|
|||
|
});
|
|||
|
|
|||
|
let branch = Rc::new(Node {
|
|||
|
value: 5,
|
|||
|
children: RefCell::new(vec![Rc::clone(&leaf)]),
|
|||
|
});
|
|||
|
}
|
|||
|
</code></pre></pre>
|
|||
|
<p><span class="caption">Listing 15-27: Creating a <code>leaf</code> node with no children
|
|||
|
and a <code>branch</code> node with <code>leaf</code> as one of its children</span></p>
|
|||
|
<p>We clone the <code>Rc<Node></code> in <code>leaf</code> and store that in <code>branch</code>, meaning the
|
|||
|
<code>Node</code> in <code>leaf</code> now has two owners: <code>leaf</code> and <code>branch</code>. We can get from
|
|||
|
<code>branch</code> to <code>leaf</code> through <code>branch.children</code>, but there’s no way to get from
|
|||
|
<code>leaf</code> to <code>branch</code>. The reason is that <code>leaf</code> has no reference to <code>branch</code> and
|
|||
|
doesn’t know they’re related. We want <code>leaf</code> to know that <code>branch</code> is its
|
|||
|
parent. We’ll do that next.</p>
|
|||
|
<h4><a class="header" href="#adding-a-reference-from-a-child-to-its-parent" id="adding-a-reference-from-a-child-to-its-parent">Adding a Reference from a Child to Its Parent</a></h4>
|
|||
|
<p>To make the child node aware of its parent, we need to add a <code>parent</code> field to
|
|||
|
our <code>Node</code> struct definition. The trouble is in deciding what the type of
|
|||
|
<code>parent</code> should be. We know it can’t contain an <code>Rc<T></code>, because that would
|
|||
|
create a reference cycle with <code>leaf.parent</code> pointing to <code>branch</code> and
|
|||
|
<code>branch.children</code> pointing to <code>leaf</code>, which would cause their <code>strong_count</code>
|
|||
|
values to never be 0.</p>
|
|||
|
<p>Thinking about the relationships another way, a parent node should own its
|
|||
|
children: if a parent node is dropped, its child nodes should be dropped as
|
|||
|
well. However, a child should not own its parent: if we drop a child node, the
|
|||
|
parent should still exist. This is a case for weak references!</p>
|
|||
|
<p>So instead of <code>Rc<T></code>, we’ll make the type of <code>parent</code> use <code>Weak<T></code>,
|
|||
|
specifically a <code>RefCell<Weak<Node>></code>. Now our <code>Node</code> struct definition looks
|
|||
|
like this:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust">
|
|||
|
<span class="boring">#![allow(unused_variables)]
|
|||
|
</span><span class="boring">fn main() {
|
|||
|
</span>use std::rc::{Rc, Weak};
|
|||
|
use std::cell::RefCell;
|
|||
|
|
|||
|
#[derive(Debug)]
|
|||
|
struct Node {
|
|||
|
value: i32,
|
|||
|
parent: RefCell<Weak<Node>>,
|
|||
|
children: RefCell<Vec<Rc<Node>>>,
|
|||
|
}
|
|||
|
<span class="boring">}
|
|||
|
</span></code></pre></pre>
|
|||
|
<p>A node will be able to refer to its parent node but doesn’t own its parent.
|
|||
|
In Listing 15-28, we update <code>main</code> to use this new definition so the <code>leaf</code>
|
|||
|
node will have a way to refer to its parent, <code>branch</code>:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">use std::rc::{Rc, Weak};
|
|||
|
</span><span class="boring">use std::cell::RefCell;
|
|||
|
</span><span class="boring">
|
|||
|
</span><span class="boring">#[derive(Debug)]
|
|||
|
</span><span class="boring">struct Node {
|
|||
|
</span><span class="boring"> value: i32,
|
|||
|
</span><span class="boring"> parent: RefCell<Weak<Node>>,
|
|||
|
</span><span class="boring"> children: RefCell<Vec<Rc<Node>>>,
|
|||
|
</span><span class="boring">}
|
|||
|
</span><span class="boring">
|
|||
|
</span>fn main() {
|
|||
|
let leaf = Rc::new(Node {
|
|||
|
value: 3,
|
|||
|
parent: RefCell::new(Weak::new()),
|
|||
|
children: RefCell::new(vec![]),
|
|||
|
});
|
|||
|
|
|||
|
println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
|
|||
|
|
|||
|
let branch = Rc::new(Node {
|
|||
|
value: 5,
|
|||
|
parent: RefCell::new(Weak::new()),
|
|||
|
children: RefCell::new(vec![Rc::clone(&leaf)]),
|
|||
|
});
|
|||
|
|
|||
|
*leaf.parent.borrow_mut() = Rc::downgrade(&branch);
|
|||
|
|
|||
|
println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
|
|||
|
}
|
|||
|
</code></pre></pre>
|
|||
|
<p><span class="caption">Listing 15-28: A <code>leaf</code> node with a weak reference to its
|
|||
|
parent node <code>branch</code></span></p>
|
|||
|
<p>Creating the <code>leaf</code> node looks similar to how creating the <code>leaf</code> node looked
|
|||
|
in Listing 15-27 with the exception of the <code>parent</code> field: <code>leaf</code> starts out
|
|||
|
without a parent, so we create a new, empty <code>Weak<Node></code> reference instance.</p>
|
|||
|
<p>At this point, when we try to get a reference to the parent of <code>leaf</code> by using
|
|||
|
the <code>upgrade</code> method, we get a <code>None</code> value. We see this in the output from the
|
|||
|
first <code>println!</code> statement:</p>
|
|||
|
<pre><code class="language-text">leaf parent = None
|
|||
|
</code></pre>
|
|||
|
<p>When we create the <code>branch</code> node, it will also have a new <code>Weak<Node></code>
|
|||
|
reference in the <code>parent</code> field, because <code>branch</code> doesn’t have a parent node.
|
|||
|
We still have <code>leaf</code> as one of the children of <code>branch</code>. Once we have the
|
|||
|
<code>Node</code> instance in <code>branch</code>, we can modify <code>leaf</code> to give it a <code>Weak<Node></code>
|
|||
|
reference to its parent. We use the <code>borrow_mut</code> method on the
|
|||
|
<code>RefCell<Weak<Node>></code> in the <code>parent</code> field of <code>leaf</code>, and then we use the
|
|||
|
<code>Rc::downgrade</code> function to create a <code>Weak<Node></code> reference to <code>branch</code> from
|
|||
|
the <code>Rc<Node></code> in <code>branch.</code></p>
|
|||
|
<p>When we print the parent of <code>leaf</code> again, this time we’ll get a <code>Some</code> variant
|
|||
|
holding <code>branch</code>: now <code>leaf</code> can access its parent! When we print <code>leaf</code>, we
|
|||
|
also avoid the cycle that eventually ended in a stack overflow like we had in
|
|||
|
Listing 15-26; the <code>Weak<Node></code> references are printed as <code>(Weak)</code>:</p>
|
|||
|
<pre><code class="language-text">leaf parent = Some(Node { value: 5, parent: RefCell { value: (Weak) },
|
|||
|
children: RefCell { value: [Node { value: 3, parent: RefCell { value: (Weak) },
|
|||
|
children: RefCell { value: [] } }] } })
|
|||
|
</code></pre>
|
|||
|
<p>The lack of infinite output indicates that this code didn’t create a reference
|
|||
|
cycle. We can also tell this by looking at the values we get from calling
|
|||
|
<code>Rc::strong_count</code> and <code>Rc::weak_count</code>.</p>
|
|||
|
<h4><a class="header" href="#visualizing-changes-to-strong_count-and-weak_count" id="visualizing-changes-to-strong_count-and-weak_count">Visualizing Changes to <code>strong_count</code> and <code>weak_count</code></a></h4>
|
|||
|
<p>Let’s look at how the <code>strong_count</code> and <code>weak_count</code> values of the <code>Rc<Node></code>
|
|||
|
instances change by creating a new inner scope and moving the creation of
|
|||
|
<code>branch</code> into that scope. By doing so, we can see what happens when <code>branch</code> is
|
|||
|
created and then dropped when it goes out of scope. The modifications are shown
|
|||
|
in Listing 15-29:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust"><span class="boring">use std::rc::{Rc, Weak};
|
|||
|
</span><span class="boring">use std::cell::RefCell;
|
|||
|
</span><span class="boring">
|
|||
|
</span><span class="boring">#[derive(Debug)]
|
|||
|
</span><span class="boring">struct Node {
|
|||
|
</span><span class="boring"> value: i32,
|
|||
|
</span><span class="boring"> parent: RefCell<Weak<Node>>,
|
|||
|
</span><span class="boring"> children: RefCell<Vec<Rc<Node>>>,
|
|||
|
</span><span class="boring">}
|
|||
|
</span><span class="boring">
|
|||
|
</span>fn main() {
|
|||
|
let leaf = Rc::new(Node {
|
|||
|
value: 3,
|
|||
|
parent: RefCell::new(Weak::new()),
|
|||
|
children: RefCell::new(vec![]),
|
|||
|
});
|
|||
|
|
|||
|
println!(
|
|||
|
"leaf strong = {}, weak = {}",
|
|||
|
Rc::strong_count(&leaf),
|
|||
|
Rc::weak_count(&leaf),
|
|||
|
);
|
|||
|
|
|||
|
{
|
|||
|
let branch = Rc::new(Node {
|
|||
|
value: 5,
|
|||
|
parent: RefCell::new(Weak::new()),
|
|||
|
children: RefCell::new(vec![Rc::clone(&leaf)]),
|
|||
|
});
|
|||
|
|
|||
|
*leaf.parent.borrow_mut() = Rc::downgrade(&branch);
|
|||
|
|
|||
|
println!(
|
|||
|
"branch strong = {}, weak = {}",
|
|||
|
Rc::strong_count(&branch),
|
|||
|
Rc::weak_count(&branch),
|
|||
|
);
|
|||
|
|
|||
|
println!(
|
|||
|
"leaf strong = {}, weak = {}",
|
|||
|
Rc::strong_count(&leaf),
|
|||
|
Rc::weak_count(&leaf),
|
|||
|
);
|
|||
|
}
|
|||
|
|
|||
|
println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
|
|||
|
println!(
|
|||
|
"leaf strong = {}, weak = {}",
|
|||
|
Rc::strong_count(&leaf),
|
|||
|
Rc::weak_count(&leaf),
|
|||
|
);
|
|||
|
}
|
|||
|
</code></pre></pre>
|
|||
|
<p><span class="caption">Listing 15-29: Creating <code>branch</code> in an inner scope and
|
|||
|
examining strong and weak reference counts</span></p>
|
|||
|
<p>After <code>leaf</code> is created, its <code>Rc<Node></code> has a strong count of 1 and a weak
|
|||
|
count of 0. In the inner scope, we create <code>branch</code> and associate it with
|
|||
|
<code>leaf</code>, at which point when we print the counts, the <code>Rc<Node></code> in <code>branch</code>
|
|||
|
will have a strong count of 1 and a weak count of 1 (for <code>leaf.parent</code> pointing
|
|||
|
to <code>branch</code> with a <code>Weak<Node></code>). When we print the counts in <code>leaf</code>, we’ll see
|
|||
|
it will have a strong count of 2, because <code>branch</code> now has a clone of the
|
|||
|
<code>Rc<Node></code> of <code>leaf</code> stored in <code>branch.children</code>, but will still have a weak
|
|||
|
count of 0.</p>
|
|||
|
<p>When the inner scope ends, <code>branch</code> goes out of scope and the strong count of
|
|||
|
the <code>Rc<Node></code> decreases to 0, so its <code>Node</code> is dropped. The weak count of 1
|
|||
|
from <code>leaf.parent</code> has no bearing on whether or not <code>Node</code> is dropped, so we
|
|||
|
don’t get any memory leaks!</p>
|
|||
|
<p>If we try to access the parent of <code>leaf</code> after the end of the scope, we’ll get
|
|||
|
<code>None</code> again. At the end of the program, the <code>Rc<Node></code> in <code>leaf</code> has a strong
|
|||
|
count of 1 and a weak count of 0, because the variable <code>leaf</code> is now the only
|
|||
|
reference to the <code>Rc<Node></code> again.</p>
|
|||
|
<p>All of the logic that manages the counts and value dropping is built into
|
|||
|
<code>Rc<T></code> and <code>Weak<T></code> and their implementations of the <code>Drop</code> trait. By
|
|||
|
specifying that the relationship from a child to its parent should be a
|
|||
|
<code>Weak<T></code> reference in the definition of <code>Node</code>, you’re able to have parent
|
|||
|
nodes point to child nodes and vice versa without creating a reference cycle
|
|||
|
and memory leaks.</p>
|
|||
|
<h2><a class="header" href="#summary" id="summary">Summary</a></h2>
|
|||
|
<p>This chapter covered how to use smart pointers to make different guarantees and
|
|||
|
trade-offs from those Rust makes by default with regular references. The
|
|||
|
<code>Box<T></code> type has a known size and points to data allocated on the heap. The
|
|||
|
<code>Rc<T></code> type keeps track of the number of references to data on the heap so
|
|||
|
that data can have multiple owners. The <code>RefCell<T></code> type with its interior
|
|||
|
mutability gives us a type that we can use when we need an immutable type but
|
|||
|
need to change an inner value of that type; it also enforces the borrowing
|
|||
|
rules at runtime instead of at compile time.</p>
|
|||
|
<p>Also discussed were the <code>Deref</code> and <code>Drop</code> traits, which enable a lot of the
|
|||
|
functionality of smart pointers. We explored reference cycles that can cause
|
|||
|
memory leaks and how to prevent them using <code>Weak<T></code>.</p>
|
|||
|
<p>If this chapter has piqued your interest and you want to implement your own
|
|||
|
smart pointers, check out <a href="https://doc.rust-lang.org/stable/nomicon/">“The Rustonomicon”</a> for more useful
|
|||
|
information.</p>
|
|||
|
<p>Next, we’ll talk about concurrency in Rust. You’ll even learn about a few new
|
|||
|
smart pointers.</p>
|
|||
|
|
|||
|
</main>
|
|||
|
|
|||
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|||
|
<!-- Mobile navigation buttons -->
|
|||
|
|
|||
|
<a rel="prev" href="ch15-05-interior-mutability.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a rel="next" href="ch16-00-concurrency.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
<div style="clear: both"></div>
|
|||
|
</nav>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|||
|
|
|||
|
<a href="ch15-05-interior-mutability.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a href="ch16-00-concurrency.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
</nav>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script type="text/javascript">
|
|||
|
window.playpen_copyable = true;
|
|||
|
</script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
|
|||
|
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="book.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
<!-- Custom JS scripts -->
|
|||
|
|
|||
|
<script type="text/javascript" src="ferris.js"></script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</body>
|
|||
|
</html>
|