<!DOCTYPE HTML>
<html lang="en" class="sidebar-visible no-js">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Creating Reference Cycles and Leaking Memory is Safe - 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" />
<base href="">
<link rel="stylesheet" href="book.css">
<link href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Source+Code+Pro:500" rel="stylesheet" type="text/css">
<link rel="shortcut icon" href="favicon.png">
<!-- Font Awesome -->
<link rel="stylesheet" href="_FontAwesome/css/font-awesome.css">
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<link rel="stylesheet" href="ayu-highlight.css">
<!-- Custom theme stylesheets -->
</head>
<body class="light">
<!-- 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 = 'light'; }
document.body.className = theme;
document.querySelector('html').className = theme + ' 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">
<ol class="chapter"><li class="affix"><a href="foreword.html">Foreword</a></li><li class="affix"><a href="ch00-00-introduction.html">Introduction</a></li><li><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> How Functions Work</a></li><li><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References & Borrowing</a></li><li><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> Slices</a></li></ol></li><li><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><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li><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><a href="ch07-00-modules.html"><strong aria-hidden="true">7.</strong> Modules</a></li><li><ol class="section"><li><a href="ch07-01-mod-and-the-filesystem.html"><strong aria-hidden="true">7.1.</strong> mod and the Filesystem</a></li><li><a href="ch07-02-controlling-visibility-with-pub.html"><strong aria-hidden="true">7.2.</strong> Controlling Visibility with pub</a></li><li><a href="ch07-03-importing-names-with-use.html"><strong aria-hidden="true">7.3.</strong> Referring to Names in Different Modules</a></li></ol></li><li><a href="ch08-00-common-collections.html"><strong aria-hidden="true">8.</strong> Common Collections</a></li><li><ol class="section"><li><a href="ch08-01-vectors.html"><strong aria-hidden="true">8.1.</strong> Vectors</a></li><li><a href="ch08-02-strings.html"><strong aria-hidden="true">8.2.</strong> Strings</a></li><li><a href="ch08-03-hash-maps.html"><strong aria-hidden="true">8.3.</strong> Hash Maps</a></li></ol></li><li><a href="ch09-00-error-handling.html"><strong aria-hidden="true">9.</strong> Error Handling</a></li><li><ol class="section"><li><a href="ch09-01-unrecoverable-errors-with-panic.html"><strong aria-hidden="true">9.1.</strong> Unrecoverable Errors with panic!</a></li><li><a href="ch09-02-recoverable-errors-with-result.html"><strong aria-hidden="true">9.2.</strong> Recoverable Errors with Result</a></li><li><a href="ch09-03-to-panic-or-not-to-panic.html"><strong aria-hidden="true">9.3.</strong> To panic! or Not To panic!</a></li></ol></li><li><a href="ch10-00-generics.html"><strong aria-hidden="true">10.</strong> Generic Types, Traits, and Lifetimes</a></li><li><ol class="section"><li><a href="ch10-01-syntax.html"><strong aria-hidden="true">10.1.</strong> Generic Data Types</a></li><li><a href="ch10-02-traits.html"><strong aria-hidden="true">10.2.</strong> Traits: Defining Shared Behavior</a></li><li><a href="ch10-03-lifetime-syntax.html"><strong aria-hidden="true">10.3.</strong> Validating References with Lifetimes</a></li></ol></li><li><a href="ch11-00-testing.html"><strong aria-hidden="true">11.</strong> Testing</a></li><li><ol class="section"><li><a href="ch11-01-writing-tests.html"><strong aria-hidden="true">11.1.</strong> Writing tests</a></li><li><a href="ch11-02-running-tests.html"><strong aria-hidden="true">11.2.</strong> Running tests</a></li><li><a href="ch11-03-test-organization.html"><strong aria-hidden="true">11.3.</strong> Test Organization</a></li></ol></li><li><a href="ch12-00-an-io-project.html"><strong aria-hidden="true">12.</strong> An I/O Project: Building a Command Line Program</a></li><li><ol class="section"><li><a href="ch12-01-accepting-command-line-arguments.html"><strong aria-hidden="true">12.1.</strong> Accepting Command Line Arguments</a></li><li><a href="ch12-02-reading-a-file.html"><strong aria-hidden="true">12.2.</strong> Reading a File</a></li><li><a href="ch12-03-improving-error-handling-and-modularity.html"><strong aria-hidden="true">12.3.</strong> Refactoring to Improve Modularity and Error Handling</a></li><li><a href="ch12-04-testing-the-librarys-functionality.html"><strong aria-hidden="true">12.4.</strong> Developing the Library’s Functionality with Test Driven Development</a></li><li><a href="ch12-05-working-with-environment-variables.html"><strong aria-hidden="true">12.5.</strong> Working with Environment Variables</a></li><li><a href="ch12-06-writing-to-stderr-instead-of-stdout.html"><strong aria-hidden="true">12.6.</strong> Writing Error Messages to Standard Error Instead of Standard Output</a></li></ol></li><li><a href="ch13-00-functional-features.html"><strong aria-hidden="true">13.</strong> Functional Language Features: Iterators and Closures</a></li><li><ol class="section"><li><a href="ch13-01-closures.html"><strong aria-hidden="true">13.1.</strong> Closures: Anonymous Functions that Can Capture Their Environment</a></li><li><a href="ch13-02-iterators.html"><strong aria-hidden="true">13.2.</strong> Processing a Series of Items with Iterators</a></li><li><a href="ch13-03-improving-our-io-project.html"><strong aria-hidden="true">13.3.</strong> Improving Our I/O Project</a></li><li><a href="ch13-04-performance.html"><strong aria-hidden="true">13.4.</strong> Comparing Performance: Loops vs. Iterators</a></li></ol></li><li><a href="ch14-00-more-about-cargo.html"><strong aria-hidden="true">14.</strong> More about Cargo and Crates.io</a></li><li><ol class="section"><li><a href="ch14-01-release-profiles.html"><strong aria-hidden="true">14.1.</strong> Customizing Builds with Release Profiles</a></li><li><a href="ch14-02-publishing-to-crates-io.html"><strong aria-hidden="true">14.2.</strong> Publishing a Crate to Crates.io</a></li><li><a href="ch14-03-cargo-workspaces.html"><strong aria-hidden="true">14.3.</strong> Cargo Workspaces</a></li><li><a href="ch14-04-installing-binaries.html"><strong aria-hidden="true">14.4.</strong> Installing Binaries from Crates.io with cargo install</a></li><li><a href="ch14-05-extending-cargo.html"><strong aria-hidden="true">14.5.</strong> Extending Cargo with Custom Commands</a></li></ol></li><li><a href="ch15-00-smart-pointers.html"><strong aria-hidden="true">15.</strong> Smart Pointers</a></li><li><ol class="section"><li><a href="ch15-01-box.html"><strong aria-hidden="true">15.1.</strong> Box<T> Points to Data on the Heap and Has a Known Size</a></li><li><a href="ch15-02-deref.html"><strong aria-hidden="true">15.2.</strong> The Deref Trait Allows Access to the Data Through a Reference</a></li><li><a href="ch15-03-drop.html"><strong aria-hidden="true">15.3.</strong> The Drop Trait Runs Code on Cleanup</a></li><li><a href="ch15-04-rc.html"><strong aria-hidden="true">15.4.</strong> Rc<T>, the Reference Counted Smart Pointer</a></li><li><a href="ch15-05-interior-mutability.html"><strong aria-hidden="true">15.5.</strong> RefCell<T> and the Interior Mutability Pattern</a></li><li><a href="ch15-06-reference-cycles.html" class="active"><strong aria-hidden="true">15.6.</strong> Creating Reference Cycles and Leaking Memory is Safe</a></li></ol></li><li><a href="ch16-00-concurrency.html"><strong aria-hidden="true">16.</strong> Fearless Concurrency</a></li><li><ol class="section"><li><a href="ch16-01-threads.html"><strong aria-hidden="true">16.1.</strong> Threads</a></li><li><a href="ch16-02-message-passing.html"><strong aria-hidden="true">16.2.</strong> Message Passing</a></li><li><a href="ch16-03-shared-state.html"><strong aria-hidden="true">16.3.</strong> Shared State</a></li><li><a href="ch16-04-extensible-concurrency-sync-and-send.html"><strong aria-hidden="true">16.4.</strong> Extensible Concurrency: Sync and Send</a></li></ol></li><li><a href="ch17-00-oop.html"><strong aria-hidden="true">17.</strong> Object Oriented Programming Features of Rust</a></li><li><ol class="section"><li><a href="ch17-01-what-is-oo.html"><strong aria-hidden="true">17.1.</strong> Characteristics of Object-Oriented Languages</a></li><li><a href="ch17-02-trait-objects.html"><strong aria-hidden="true">17.2.</strong> Using Trait Objects that Allow for Values of Different Types</a></li><li><a href="ch17-03-oo-design-patterns.html"><strong aria-hidden="true">17.3.</strong> Implementing an Object-Oriented Design Pattern</a></li></ol></li><li><a href="ch18-00-patterns.html"><strong aria-hidden="true">18.</strong> Patterns Match the Structure of Values</a></li><li><ol class="section"><li><a href="ch18-01-all-the-places-for-patterns.html"><strong aria-hidden="true">18.1.</strong> All the Places Patterns May be Used</a></li><li><a href="ch18-02-refutability.html"><strong aria-hidden="true">18.2.</strong> Refutability: Whether a Pattern Might Fail to Match</a></li><li><a href="ch18-03-pattern-syntax.html"><strong aria-hidden="true">18.3.</strong> All the Pattern Syntax</a></li></ol></li><li><a href="ch19-00-advanced-features.html"><strong aria-hidden="true">19.</strong> Advanced Features</a></li><li><ol class="section"><li><a href="ch19-01-unsafe-rust.html"><strong aria-hidden="true">19.1.</strong> Unsafe Rust</a></li><li><a href="ch19-02-advanced-lifetimes.html"><strong aria-hidden="true">19.2.</strong> Advanced Lifetimes</a></li><li><a href="ch19-03-advanced-traits.html"><strong aria-hidden="true">19.3.</strong> Advanced Traits</a></li><li><a href="ch19-04-advanced-types.html"><strong aria-hidden="true">19.4.</strong> Advanced Types</a></li><li><a href="ch19-05-advanced-functions-and-closures.html"><strong aria-hidden="true">19.5.</strong> Advanced Functions & Closures</a></li></ol></li><li><a href="ch20-00-final-project-a-web-server.html"><strong aria-hidden="true">20.</strong> Final Project: Building a Multithreaded Web Server</a></li><li><ol class="section"><li><a href="ch20-01-single-threaded.html"><strong aria-hidden="true">20.1.</strong> A Single Threaded Web Server</a></li><li><a href="ch20-02-multithreaded.html"><strong aria-hidden="true">20.2.</strong> Turning our Single Threaded Server into a Multithreaded Server</a></li><li><a href="ch20-03-graceful-shutdown-and-cleanup.html"><strong aria-hidden="true">20.3.</strong> Graceful Shutdown and Cleanup</a></li></ol></li><li><a href="appendix-00.html"><strong aria-hidden="true">21.</strong> Appendix</a></li><li><ol class="section"><li><a href="appendix-01-keywords.html"><strong aria-hidden="true">21.1.</strong> A - Keywords</a></li><li><a href="appendix-02-operators.html"><strong aria-hidden="true">21.2.</strong> B - Operators and Symbols</a></li><li><a href="appendix-03-derivable-traits.html"><strong aria-hidden="true">21.3.</strong> C - Derivable Traits</a></li><li><a href="appendix-04-macros.html"><strong aria-hidden="true">21.4.</strong> D - Macros</a></li><li><a href="appendix-05-translation.html"><strong aria-hidden="true">21.5.</strong> E - Translations</a></li><li><a href="appendix-06-nightly-rust.html"><strong aria-hidden="true">21.6.</strong> F - How Rust is Made and “Nightly Rust”</a></li></ol></li></ol>
</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 <span class="default">(default)</span></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>
<a class="header" href="ch15-06-reference-cycles.html#reference-cycles-can-leak-memory" id="reference-cycles-can-leak-memory"><h2>Reference Cycles Can Leak Memory</h2></a>
<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>
<a class="header" href="ch15-06-reference-cycles.html#creating-a-reference-cycle" id="creating-a-reference-cycle"><h3>Creating a Reference Cycle</h3></a>
<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"># fn main() {}
use std::rc::Rc;
use std::cell::RefCell;
use 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(_, ref 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 in 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"># use List::{Cons, Nil};
# use std::rc::Rc;
# use std::cell::RefCell;
# #[derive(Debug)]
# enum List {
# Cons(i32, RefCell<Rc<List>>),
# Nil,
# }
#
# impl List {
# fn tail(&self) -> Option<&RefCell<Rc<List>>> {
# match *self {
# Cons(_, ref item) => Some(item),
# Nil => None,
# }
# }
# }
#
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 in each of the
<code>Rc<List></code> instances in <code>a</code> and <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>
<p><img alt="Reference cycle of lists" src="img/trpl15-04.svg" class="center" /></p>
<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>
<a class="header" href="ch15-06-reference-cycles.html#preventing-reference-cycles-turning-an-rct-into-a-weakt" id="preventing-reference-cycles-turning-an-rct-into-a-weakt"><h3>Preventing Reference Cycles: Turning an <code>Rc<T></code> into a <code>Weak<T></code></h3></a>
<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>
<a class="header" href="ch15-06-reference-cycles.html#creating-a-tree-data-structure-a-node-with-child-nodes" id="creating-a-tree-data-structure-a-node-with-child-nodes"><h4>Creating a Tree Data Structure: a <code>Node</code> with Child Nodes</h4></a>
<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">
# #![allow(unused_variables)]
#fn main() {
use std::rc::Rc;
use std::cell::RefCell;
#[derive(Debug)]
struct Node {
value: i32,
children: RefCell<Vec<Rc<Node>>>,
}
#}</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"># use std::rc::Rc;
# use std::cell::RefCell;
#
# #[derive(Debug)]
# struct Node {
# value: i32,
# children: RefCell<Vec<Rc<Node>>>,
# }
#
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>
<a class="header" href="ch15-06-reference-cycles.html#adding-a-reference-from-a-child-to-its-parent" id="adding-a-reference-from-a-child-to-its-parent"><h4>Adding a Reference from a Child to Its Parent</h4></a>
<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">
# #![allow(unused_variables)]
#fn main() {
use std::rc::{Rc, Weak};
use std::cell::RefCell;
#[derive(Debug)]
struct Node {
value: i32,
parent: RefCell<Weak<Node>>,
children: RefCell<Vec<Rc<Node>>>,
}
#}</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"># use std::rc::{Rc, Weak};
# use std::cell::RefCell;
#
# #[derive(Debug)]
# struct Node {
# value: i32,
# parent: RefCell<Weak<Node>>,
# children: RefCell<Vec<Rc<Node>>>,
# }
#
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>
<a class="header" href="ch15-06-reference-cycles.html#visualizing-changes-to-strong_count-and-weak_count" id="visualizing-changes-to-strong_count-and-weak_count"><h4>Visualizing Changes to <code>strong_count</code> and <code>weak_count</code></h4></a>
<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"># use std::rc::{Rc, Weak};
# use std::cell::RefCell;
#
# #[derive(Debug)]
# struct Node {
# value: i32,
# parent: RefCell<Weak<Node>>,
# children: RefCell<Vec<Rc<Node>>>,
# }
#
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>
<a class="header" href="ch15-06-reference-cycles.html#summary" id="summary"><h2>Summary</h2></a>
<p>This chapter covered how to use smart pointers to make different guarantees and
trade-offs than 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 src="searchindex.js" type="text/javascript" charset="utf-8"></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 -->
</body>
</html>
distrib
>
Mageia
>
6
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
4e2dbb669434a7691662cb2f0ad38972
>
files
>
549
