Rust の所有権と借用によってメモリの安全性が強化されます

実際に何が起こっているのかを理解していないと、Rust の所有権と借用が混乱する可能性があります。これは、以前に学んだプログラミング スタイルを新しいパラダイムに適用する場合に特に当てはまります。私たちはこれをパラダイムシフトと呼んでいます。所有権は斬新なアイデアですが、最初は理解するのが難しいですが、取り組むほど簡単になります。 Rust の所有権と借用について詳しく説明する前に、まず「メモリの安全性」と「メモリ リーク」とは何か、そしてプログラミング言語がそれらをどのように処理するかを理解しましょう。 メモリの安全性とは何ですか? メモリの安全性とは、メモリ ポインタまたは参照が常に有効なメモリを参照するソフトウェア アプリケーションの状態を指します。メモリが破損する可能性があるため、プログラムがメモリセーフでない場合、プログラムの動作に関する保証はほとんどありません。簡単に言えば、プログラムが実際にメモリセーフでない場合、その機能に関する保証はほとんどありません。メモリが安全でないプログラムを扱う場合、悪意のある者がこの欠陥を利用して秘密情報を読み取ったり、他人のマシンで任意のコードを実行したりできます。 疑似コードを使用して、有効なメモリとは何かを見てみましょう。 // pseudocode #1 - shows valid reference { // scope starts here int x = 5 int y = &x } // scope ends here 上記の疑似コードでは、値 が割り当てられた変数 を作成しました。 演算子またはキーワードを使用して参照を作成します。したがって、 構文を使用すると、 の値を参照する参照を作成できます。簡単に言うと、 を所有する変数 と への参照である変数 を作成しました。 10 x & &x x 5 x x y 変数 と の両方が同じブロックまたはスコープ内にあるため、変数 には の値を参照する有効な参照があります。その結果、変数 の値は になります。 x y y x y 5 以下の疑似コードを見てください。ご覧のとおり、 のスコープは、それが作成されたブロックに限定されています。 のスコープ外にアクセスしようとすると、ダングリング参照が発生します。ぶら下がり参照…？正確には何ですか？ x x // pseudocode #2 - shows invalid reference aka dangling reference { // scope starts here int x = 5 } // scope ends here int y = &x // can't access x from here; creates dangling reference ダングリング リファレンス ダングリング参照は、他の誰かに与えられた、または解放された (解放された) メモリ位置を指すポインタです。プログラム (別名 ) が、解放または消去されたメモリを参照すると、クラッシュしたり、非決定論的な結果を引き起こしたりする可能性があります。 process そうは言っても、 の安全性は、プログラマーが無効なデータを処理できるようにする一部のプログラミング言語の特性です。その結果、メモリの安全性の欠如によりさまざまな問題が発生し、次の主要なセキュリティの脆弱性を引き起こす可能性があります。 メモリ 範囲外読み取り 境界外書き込み 解放後使用 メモリの安全性が損なわれることによって引き起こされる脆弱性は、他の多くの重大なセキュリティ脅威の根源です。残念ながら、これらの脆弱性を明らかにすることは、開発者にとって非常に困難な場合があります。 メモリ リークとは メモリ リークとは何か、およびその結果は何かを理解することが重要です。 は、開発者が不要になった メモリの割り当てられたブロックを解放できない、意図しない形式のメモリ消費です。これは、メモリの安全性とは正反対です。さまざまなメモリの種類については後で詳しく説明しますが、現時点では、 にはコンパイル時に既知の固定長の変数が格納されるのに対し、後で実行時に変更される可能性のある変数のサイズは に配置する必要があることを知っておいてください。 メモリ リーク ヒープ スタック heap ヒープ メモリの割り当てと比較すると、スタック メモリの割り当てはより安全であると見なされます。これは、プログラマまたはプログラム ランタイム自体のいずれかによって、メモリが関連性または不要になったときにメモリが自動的に解放されるためです。 ただし、プログラマがヒープ上にメモリを生成し、ガベージ コレクタがない状態でメモリを削除しない場合 (C および C++ の場合)、メモリ リークが発生します。また、メモリの割り当てを解除せずにメモリのチャンクへのすべての参照を失うと、メモリ リークが発生します。私たちのプログラムは引き続きそのメモリを所有しますが、それを再び使用する方法はありません。 多少のメモリ リークは問題ではありませんが、プログラムが大量のメモリを割り当て、その割り当てを解除しない場合、プログラムのメモリ フットプリントは増加し続け、結果としてサービス拒否が発生します。 プログラムが終了すると、オペレーティング システムは、それが所有するすべてのメモリを即座に回復します。その結果、メモリ リークは実行中のプログラムにのみ影響します。プログラムが終了すると、効果はありません。 メモリ リークの主な影響について見ていきましょう。 メモリ リークは、使用可能なメモリ (ヒープ メモリ) の量を減らすことによって、コンピューターのパフォーマンスを低下させます。最終的には、システムの全体または一部が正しく動作しなくなったり、大幅に遅くなったりします。クラッシュは、一般的にメモリ リークに関連しています。 メモリ リークを防ぐ方法を見つけるためのアプローチは、使用しているプログラミング言語によって異なります。メモリ リークは、小さくてほとんど「気付かない問題」として始まる場合がありますが、非常に急速にエスカレートし、影響を受けるシステムを圧倒する可能性があります。可能な限り、それらを監視し、それらを成長させておくのではなく、修正するための措置を講じる必要があります。 メモリの安全性とメモリ リーク メモリ リークとメモリの安全性の問題は、防止と修復の観点から最も注目されている 2 つのタイプの問題です。一方を修正しても他方が自動的に修正されるわけではないことに注意してください。 さまざまな種類のメモリとその動作 先に進む前に、コードが実行時に使用するさまざまな種類のメモリを理解することが重要です。 メモリには次の 2 種類があり、メモリの構造が異なります。 プロセッサ レジスタ 静的 スタック ヒープ と メモリの両方のタイプは、この記事の範囲外です。 プロセッサ レジスタ 静的 スタック メモリとそのしくみ スタックは、データを受信した順序で格納し、逆の順序で削除します。項目は 後入れ先出し (LIFO) 順でスタックからアクセスできます。スタックにデータを追加することを「プッシュ」と呼び、スタックからデータを削除することを「ポッピング」と呼びます。 、 スタックに格納されるすべてのデータは、既知の固定サイズである必要があります。コンパイル時のサイズが不明なデータ、または後で変更される可能性のあるサイズのデータは、代わりにヒープに格納する必要があります。 開発者は、スタック メモリの と について心配する必要はありません。スタック メモリの割り当てと割り当て解除は、コンパイラによって「自動的に行われます」。これは、スタック上のデータが関連性を失った (範囲外になった) 場合、介入を必要とせずに自動的に削除されることを意味します。 割り当て 解放 この種のメモリ割り当ては、 割り当てとも呼ばれます。これは、関数の実行が終了するとすぐに、その関数に属するすべてのデータがスタックから「自動的に」フラッシュされるためです。 一時メモリ Rust のすべてのプリミティブ型はスタック上に存在します。数値、文字、スライス、ブール値、固定サイズの配列、プリミティブを含むタプル、関数ポインターなどの型はすべてスタックに配置できます。 ヒープメモリとその仕組み スタックとは異なり、データをヒープに置くとき、一定量のスペースを要求します。メモリ アロケータは、ヒープ内の十分な大きさの空いている場所を見つけ、使用中としてマークし、その場所のアドレスへの参照を返します。これは、 と呼ばれます。 割り当て アロケーターは新しいデータを配置するために空の場所を探す必要がないため、ヒープへの割り当てはスタックへのプッシュよりも遅くなります。さらに、ヒープ上のデータにアクセスするにはポインターをたどる必要があるため、スタック上のデータにアクセスするよりも遅くなります。コンパイル時に割り当ておよび割り当て解除されるスタックとは異なり、ヒープ メモリはプログラムの命令の実行中に割り当ておよび割り当て解除されます。 一部のプログラミング言語では、ヒープ メモリを割り当てるためにキーワード を使用します。この キーワード (別名 ) は、ヒープでのメモリ割り当ての要求を示します。ヒープに十分なメモリがある場合、 演算子はメモリを初期化し、新しく割り当てられたメモリの一意のアドレスを返します。 new new operator new ヒープ メモリは、プログラマまたはランタイムによって "明示的に" 割り当て解除されることに注意してください。 他のさまざまなプログラミング言語はメモリの安全性をどのように保証していますか? メモリ管理、特にヒープ メモリに関しては、プログラミング言語に次の特性を持たせたいと考えています。 メモリが不要になったら、実行時のオーバーヘッドなしで、できるだけ早くメモリを解放することをお勧めします。 解放されたデータへの参照 (別名ダングリング参照) を維持するべきではありません。そうしないと、クラッシュやセキュリティの問題が発生する可能性があります。 メモリの安全性は、プログラミング言語によって次の方法でさまざまな方法で保証されます。 (C、C++ で採用) 明示的なメモリー解放 (Java、Python、および C# で採用) 自動または暗黙のメモリー解放 リージョンベースのメモリ管理 線形または固有の型システム と はどちらも、この記事の範囲を超えています。 領域ベースのメモリ管理 線形型のシステム 手動または明示的なメモリ割り当て解除 明示的なメモリ管理を使用する場合、プログラマは割り当てられたメモリを「手動で」解放または消去する必要があります。 「割り当て解除」演算子 (たとえば、C の ) は、明示的なメモリ割り当て解除を行う言語に存在します。 delete C や C++ などのシステム言語ではガベージ コレクションのコストが高すぎるため、明示的なメモリ割り当てが引き続き存在します。 メモリを解放する責任をプログラマーに任せることには、プログラマーが変数のライフサイクルを完全に制御できるという利点があります。ただし、解放演算子を誤って使用すると、実行中にソフトウェア障害が発生する可能性があります。実際、この手動の割り当てとリリースのプロセスはエラーを起こしやすいです。一般的なコーディング エラーには次のようなものがあります。 ダングリングリファレンス メモリーリーク それにもかかわらず、ガベージ コレクションよりも手動のメモリ管理を優先しました。これは、より多くの制御が可能で、パフォーマンスが向上するためです。システムプログラミング言語の目標は、可能な限り「金属に近づく」ことであることに注意してください。言い換えれば、トレードオフで便利な機能よりも優れたパフォーマンスを優先します。 解放した値へのポインターが使用されないようにすることは、完全に私たち (開発者) の責任です。 最近では、これらのエラーを回避するためのいくつかの実証済みのパターンがありましたが、最終的には、正しいメモリ管理方法を一貫して適用する必要がある厳密なコード規律を維持する必要があります。 重要なポイントは次のとおりです。 メモリ管理をより細かく制御できます。 ぶら下がり参照とメモリ リークの結果、安全性が低下します。 開発期間が長くなります。 自動または暗黙的なメモリ割り当て解除 自動メモリ管理は、Java を含む最新のすべてのプログラミング言語で不可欠な機能になっています。 自動メモリ割り当て解除の場合、 は自動メモリ マネージャとして機能します。これらのガベージ コレクターは定期的にヒープを調べ、使用されていないメモリのチャンクをリサイクルします。これらは、私たちに代わってメモリの割り当てと解放を管理します。したがって、メモリ管理タスクを実行するためにコードを記述する必要はありません。ガベージ コレクターによってメモリ管理の責任から解放されるので、これは素晴らしいことです。もう1つの利点は、開発時間を短縮できることです。 ガベージ コレクタ 一方、ガベージ コレクションには多くの欠点があります。ガベージ コレクションの間、プログラムは一時停止し、次に進む前に何をクリーンアップする必要があるかを判断するのに時間を費やす必要があります。 さらに、自動メモリ管理では、より多くのメモリが必要になります。これは、メモリと CPU サイクルの両方を消費するメモリ割り当て解除をガベージ コレクタが実行するためです。その結果、特にリソースが限られている大規模なアプリケーションでは、自動メモリ管理によってアプリケーションのパフォーマンスが低下する可能性があります。 重要なポイントは次のとおりです。 開発者がメモリを手動で解放する必要がなくなります。 ダングリング参照やメモリ リークのない、効率的なメモリの安全性を提供します。 よりシンプルでわかりやすいコード。 開発サイクルの高速化。 メモリ管理をあまり制御できません。 メモリと CPU サイクルの両方を消費するため、レイテンシが発生します。 Rust はメモリの安全性をどのように保証しますか? 一部の言語では、プログラムの実行中に使用されなくなったメモリを探す が提供されます。また、プログラマが する必要があるものもあります。これらのモデルにはどちらも利点と欠点があります。ガベージ コレクションは、おそらく最も広く使用されていますが、いくつかの欠点があります。リソースとパフォーマンスを犠牲にして、開発者の生活を楽にします。 ガベージ コレクション 明示的にメモリを割り当てて解放 そうは言っても、1つは効率的なメモリ管理 を提供し、もう1つはダングリング参照とメモリリークを排除することでより高い を提供します。 Rust は両方の長所を兼ね備えています。 制御 安全性 Rust は、メモリの安全性を確保するためにコンパイラが検証する一連のルールを備えた に基づいて、他の 2 つとは異なるアプローチをとっています。これらの規則のいずれかに違反すると、プログラムはコンパイルされません。実際、所有権は、実行時のガベージ コレクションをメモリの安全性のためのコンパイル時のチェックに置き換えます。 所有権モデル 所有権は、私のような多くのプログラマーにとって新しい概念であるため、慣れるまでに時間がかかります。 所有 この時点で、データがメモリに格納される方法についての基本的な理解が得られました。 Rust での を詳しく見てみましょう。 Rust の最大の特徴は所有権です。これにより、コンパイル時のメモリの安全性が保証されます。 所有権 まず、「所有権」を最も文字通りの意味で定義しましょう。所有権とは、「何か」を合法的に「所有」し、「支配」している状態です。そうは言っ を特定する必要があります。 Rust では、各値には と呼ばれる変数があります。簡単に言えば、変数は所有者であり、変数の値は所有者が所有および制御するものです。 ても、所有者が誰であり 、所有者が所有および管理しているもの owner 所有権モデルでは、メモリを所有する変数がスコープ外になると、メモリは自動的に解放 (解放) されます。値がスコープ外になるか、何らかの理由でその有効期間が終了すると、デストラクタが呼び出されます。デストラクタ、特に自動化されたデストラクタは、参照を削除してメモリを解放することにより、プログラムから値の痕跡を取り除く関数です。 借入チェッカー Rust は を通じて所有権を実装します。 .借用チェッカーは、プログラム全体でデータが使用されている場所を追跡する Rust コンパイラのコンポーネントであり、所有権の規則に従うことで、データを解放する必要がある場所を特定できます。さらに、ボロー チェッカーは、割り当て解除されたメモリが実行時にアクセスできないようにします。同時突然変異 (変更) によって引き起こされるデータ競合の可能性も排除します。 借用チェッカー 静的アナライザー 所有規則 前述のように、所有権モデルは と呼ばれる一連のルールに基づいて構築されており、これらのルールは比較的単純です。 Rust コンパイラ (rustc) は、次の規則を適用します。 所有権ルール Rust では、各値にはその所有者と呼ばれる変数があります。 一度に存在できる所有者は 1 人だけです。 所有者が範囲外になると、値は削除されます。 次のメモリ エラーは、これらのコンパイル時の所有権チェック ルールによって保護されます。 これは、ポインタが参照していたデータが含まれていないメモリ アドレスを参照が指す場所です。このポインターは、null またはランダム データを指します。 ダングリング参照: これは、メモリが解放された後にアクセスされる場所であり、クラッシュする可能性があります。このメモリ ロケーションは、ハッカーがコードを実行するために使用することもできます。 解放後に使用: これは、割り当てられたメモリが解放され、その後再び解放される場所です。これにより、プログラムがクラッシュし、機密情報が公開される可能性があります。これにより、ハッカーは選択したコードを実行することもできます。 二重解放: これは、プログラムがアクセスを許可されていないメモリにアクセスしようとする場所です。 セグメンテーション違反: これは、データの量がメモリ バッファの記憶容量を超え、プログラムがクラッシュする原因となる場所です。 バッファ オーバーラン: 各所有権ルールの詳細に入る前に、 、 、および の違いを理解することが重要です。 copy move clone コピー 固定サイズの型 (特にプリミティブ型) は、 に格納し、そのスコープが終了したときにポップオフできます。コードの別の部分で同じ値が必要な場合は、すばやく簡単にコピーして新しい独立した変数を作成できます。別のスコープ。スタック メモリのコピーは安価で高速であるため、固定サイズのプリミティブ型は セマンティクスを持つと言われています。完全なレプリカ (複製) を低コストで作成します。 スタック コピー 固定サイズのプリミティブ型は、コピーを作成するためのコピー トレイトを実装していることに注意してください。 let x = "hello"; let y = x; println!("{}", x) // hello println!("{}", y) // hello (ヒープが割り当てられ、拡張可能) と (固定サイズで変更不可) です。 Rust には、2 種類の文字列があります。 String &str はスタックに格納されるため、その値をコピーして の別のコピーを生成する方が簡単です。これは、ヒープに格納されている値には当てはまりません。スタック フレームは次のようになります。 x y データを複製すると、プログラムの実行時間とメモリ消費量が増加します。したがって、コピーは大量のデータには適していません。 動く Rust 用語では、「移動」とは、メモリの所有権が別の所有者に譲渡されることを意味します。ヒープに格納されている複合型の場合を考えてみましょう。 let s1 = String::from("hello"); let s2 = s1; 2 行目 (つまり ) が の値のコピーを作成し、それを にバインドすると仮定するかもしれません。しかし、そうではありません。 let s2 = s1; s1 s2 以下を見て、フードの下で に何が起こっているかを確認してください。 String は 3 つの部分で構成され、 に格納されます。実際のコンテンツ (この場合はこんにちは) は に格納されます。 String スタック heap - 文字列の内容を保持するメモリを指します。 ポインタ - の内容が現在使用しているメモリ量 (バイト単位) です。 長さ String - がアロケータから受け取ったメモリの総量 (バイト単位) です。 Capacity String つまり、メタデータはスタックに保持され、実際のデータはヒープに保持されます。 を に割り当てると、 メタデータがコピーされます。つまり、スタックにあるポインター、長さ、および容量がコピーされます。ポインターが参照するヒープ上のデータはコピーしません。メモリ内のデータ表現は次のようになります。 s1 s2 String Rust がヒープ データもコピーした場合にメモリがどのように見えるかは、以下のような表現では ことに注意してください。 Rust がこれを実行した場合、ヒープ データが大きい場合、 操作はランタイム パフォーマンスの点で非常に遅くなる可能性があります。 ない s2 = s1 複合型がスコープ外になると、Rust は 関数を呼び出して明示的にヒープ メモリの割り当てを解除することに注意してください。ただし、図 6 の両方のデータ ポインターは同じ場所を指していますが、これは Rust の動作ではありません。詳細については、後ほど説明します。 drop 前述のように、 を に割り当てると、変数 は のメタデータ (ポインター、長さ、および容量) のコピーを受け取ります。しかし、 が に割り当てられるとどうなるでしょうか? Rust はもはや が有効であるとは見なしません。はい、あなたはそれを正しく読みました。 s1 s2 s2 s1 s1 s2 s1 この の代入について少し考えてみましょう。この割り当ての後、Rust がまだ を有効であると見なした場合に何が起こるかを考えてみてください。 と が範囲外になると、両方とも同じメモリを解放しようとします。うーん、それは良くない。これは と呼ばれ、メモリの安全性に関するバグの 1 つです。メモリの破損は、メモリを 2 回解放することで発生する可能性があり、セキュリティ リスクを引き起こします。 let s2 = s1 s1 s2 s1 double free error メモリの安全性を確保するために、Rust は行 の後で を無効と見なしました。したがって、 がスコープから外れた場合、Rust は何も解放する必要はありません。 が作成された後に を使用しようとするとどうなるかを調べます。 let s2 = s1 s1 s1 s2 s1 let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. We'll get an error. Rust が無効化された参照を使用できないため、以下のようなエラーが発生します。 $ cargo run Compiling playground v0.0.1 (/playground) error[E0382]: borrow of moved value: `s1` --> src/main.rs:6:28 | 3 | let s1 = String::from("hello"); | -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait 4 | let s2 = s1; | -- value moved here 5 | 6 | println!("{}, world!", s1); | ^^ value borrowed here after move | = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info) For more information about this error, try `rustc --explain E0382`. Rust は という行の後に のメモリの所有権を に「移動」したため、 は無効であると見なされました。 s1 が無効化された後のメモリ表現は次のとおりです。 let s2 = s1 s1 s2 s1 だけが有効なままである場合、範囲外になると、それだけでメモリが解放されます。その結果、Rust では の可能性が排除されます。それは素晴らしいです！ s2 二重解放エラー クローン スタック データだけでなく、 のヒープ データを深くコピー たい場合は、 というメソッドを使用できます。 clone メソッドの使用例を次に示します。 String し clone let s1 = String::from("hello"); let s2 = s1.clone(); println!("s1 = {}, s2 = {}", s1, s2); clone メソッドを使用すると、ヒープ データは s2 にコピーされます。これは完全に機能し、次の動作を生成します。 clone メソッドを使用すると、重大な結果が生じます。データをコピーするだけでなく、2 つの間の変更を同期しません。一般に、クローンは慎重に計画し、その結果を十分に認識している必要があります。 ここまでで、コピー、移動、クローンを区別できるはずです。ここで、各所有権ルールを詳しく見てみましょう。 所有権規則 1 各値には、その所有者と呼ばれる変数があります。これは、すべての値が変数によって所有されていることを意味します。以下の例では、変数 が文字列へのポインターを所有し、2 行目の変数 が値 1 を所有しています。 s x let s = String::from("Rule 1"); let n = 1; 所有権のルール 2 ある時点で値の所有者は 1 人だけです。多くのペットを飼うことができますが、所有モデルに関して言えば、いつでも 1 つの値しかありません :-) コンパイル時に既知の固定サイズである を使用した例を見てみましょう。 プリミティブ let x = 10; let y = x; let z = x; 10 を取り、それを に割り当てました。つまり、 は 10 を所有しています。次に、 を取得して に代入し、それを にも代入します。所有者は一度に 1 人しか存在できないことはわかっていますが、ここではエラーは発生していません。ここで何が起こっているかというと、x を新しい変数に代入するたびに、コンパイラが のコピーを作成しているということです。 x x x y z x このためのスタック フレームは次のようになります: 、 および 。ただし、これは 、 、および のように当てはまらないようです。ご存知のように、 はこの値 10 の唯一の所有者であり、 も もこの値を所有することはできません。 x = 10 y = 10 z = 10 x = 10 y = x z = x x y z スタック メモリのコピーは安価で高速であるため、固定サイズのプリミティブ型は セマンティクスを持つと言われますが、複合型は所有権を します (前述のとおり)。したがって、この場合、コンパイラは します。 コピー 移動 コピーを作成 このときの挙動は 他のプログラミング言語と同じです。所有権のルールを説明するには、複雑なデータ型が必要です。 変数バインディング ヒープに保存されているデータを見て、Rust がそれをクリーンアップするタイミングをどのように理解するかを見てみましょう。 String 型は、このユース ケースの優れた例です。 String の所有権関連の動作に焦点を当てます。ただし、これらの原則は他の複雑なデータ型にも適用されます。 ご存知のように、複合型はヒープ上のデータを管理し、その内容はコンパイル時には不明です。前に見たのと同じ例を見てみましょう。 let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. We'll get an error. 型の場合、サイズが膨張してヒープに格納されることがあります。これの意味は： String 実行時に、メモリ アロケータからメモリを要求する必要があります (最初の部分と呼びましょう)。 の使用が終了したら、このメモリをアロケータに戻す (解放する) 必要があります (これを 2 番目の部分と呼びましょう)。 String 私たち (開発者) は最初の部分を処理しました: を呼び出すと、その実装は必要なメモリを要求します。この部分は、プログラミング言語間でほぼ共通です。 String::from ただし、第 2 部は異なります。ガベージ コレクター (GC) を備えた言語では、GC が使用されなくなったメモリを追跡してクリーンアップするため、心配する必要はありません。ガベージ コレクターのない言語では、メモリが不要になった時期を特定し、明示的に解放するように要求するのは私たちの責任です。これを正しく行うことは、常に困難なプログラミング タスクでした。 忘れると記憶が無駄になります。 早すぎると変数が無効になります。 2回やるとバグります。 Rust は、私たちの生活を楽にする斬新な方法でメモリの解放を処理します。メモリを所有する変数がスコープ外になると、メモリは自動的に返されます。 ビジネスに戻りましょう。 Rust では、複雑な型の場合、値を変数に代入する、関数に渡す、関数から返すなどの操作は、値をコピーせずに移動します。簡単に言うと、複合型は所有権を移動します。 複合型がスコープ内になくなると、Rust は drop 関数を呼び出して明示的にヒープ メモリの割り当てを解除します。 所有権のルール 3 所有者が範囲外になると、値は削除されます。前のケースをもう一度考えてみましょう。 let s1 = String::from("hello"); let s2 = s1; println!("{}, world!", s1); // Won't compile. The value of s1 has already been dropped. が に代入された後 ( 代入ステートメントで)、 の値がドロップされました。したがって、 はこの代入後は無効になります。 s1 が削除された後のメモリ表現は次のとおりです。 s1 s2 let s2 = s1 s1 s1 所有権の移動方法 Rust プログラムで、ある変数から別の変数に所有権を譲渡するには、次の 3 つの方法があります。 ある変数の値を別の変数に代入する (既に説明しました)。 関数に値を渡す。 関数からの戻り。 関数に値を渡す 関数に値を渡す方法は、変数に値を代入する方法と似ています。代入と同様に、変数を関数に渡すと、変数が移動またはコピーされます。次の例を見てください。これは、コピーと移動の両方の使用例を示しています。 fn main() { let s = String::from("hello"); // s comes into scope move_ownership(s); // s's value moves into the function... // so it's no longer valid from this // point forward let x = 5; // x comes into scope makes_copy(x); // x would move into the function // It follows copy semantics since it's // primitive, so we use x afterward } // Here, x goes out of scope, then s. But because s's value was moved, nothing // special happens. fn move_ownership(some_string: String) { // some_string comes into scope println!("{}", some_string); } // Here, some_string goes out of scope and `drop` is called. // The occupied memory is freed. fn makes_copy(some_integer: i32) { // some_integer comes into scope println!("{}", some_integer); } // Here, some_integer goes out of scope. Nothing special happens. の呼び出しの後に s を使用しようとすると、Rust はコンパイル時エラーをスローします。 move_ownership 関数から戻る 戻り値によって所有権を譲渡することもできます。次の例は、値を返す関数を示しています。注釈は前の例と同じです。 fn main() { let s1 = gives_ownership(); // gives_ownership moves its return // value into s1 let s2 = String::from("hello"); // s2 comes into scope let s3 = takes_and_gives_back(s2); // s2 is moved into // takes_and_gives_back, which also // moves its return value into s3 } // Here, s3 goes out of scope and is dropped. s2 was moved, so nothing // happens. s1 goes out of scope and is dropped. fn gives_ownership() -> String { // gives_ownership will move its // return value into the function // that calls it let some_string = String::from("yours"); // some_string comes into scope some_string // some_string is returned and // moves out to the calling // function } // This function takes a String and returns it fn takes_and_gives_back(a_string: String) -> String { // a_string comes into // scope a_string // a_string is returned and moves out to the calling function } 変数の所有権は、常に同じパターンに従います。 。データの所有権が別の変数に移されていない限り、ヒープ上のデータを含む変数がスコープ外になると、その値は によって消去されます。 値は、別の変数に代入されると移動されます drop これにより、 モデルとは何か、Rust が値を処理する方法 (値を相互に割り当てたり、関数に渡したり関数から渡したりするなど) にどのように影響するかについての基本的な理解が得られることを願っています。 所有権 持続する。もう一つ… Rust の所有権モデルには、すべての優れた機能と同様に、特定の欠点があります。 Rust の作業を開始すると、特定の不便さにすぐに気付きます。所有権を取得してから各関数で所有権を返すのは少し不便であることに気付いたかもしれません。 関数を再度使用したい場合、その関数によって返される他のデータに加えて、関数に渡すすべてのものを返さなければならないのは面倒です。関数が値の所有権を取得せずに値を使用するようにしたい場合はどうすればよいでしょうか? 次の例を考えてみましょう。所有権が 関数に転送されると、最初にそれを所有していた 関数 ( 内) で変数 を使用できなくなるため、以下のコードはエラーになります。 print_vector main println! v fn main() { let v = vec![10,20,30]; print_vector(v); println!("{}", v[0]); // this line gives us an error } fn print_vector(x: Vec ) { println!("Inside print_vector function {:?}",x); } 所有権の追跡は簡単に思えるかもしれませんが、大規模で複雑なプログラムを扱うようになると複雑になることがあります。そのため、所有権を譲渡せずに価値を譲渡する方法が必要であり、そこで の概念が登場します。 借用 借入 文字通りの意味での借用とは、返すという約束で何かを受け取ることを指します。 Rust のコンテキストでは、 は、ある時点で所有者に返さなければならないため、所有権を主張せずに値にアクセスする方法です。 借用 値を借用するときは、そのメモリ アドレスを 演算子で参照します。 は と呼ばれます。参照自体は特別なものではなく、中身は単なるアドレスです。 C ポインターに精通している方にとって、参照とは、別の変数に属する (別の変数 する) 値を含むメモリへの です。 Rust では参照を null にできないことに注意してください。実際、 です。これはポインタの最も基本的なタイプです。ほとんどの言語には 1 つのタイプのポインターしかありませんが、Rust には 1 つだけではなく、さまざまな種類のポインターがあります。ポインターとそのさまざまな種類は別のトピックであり、個別に説明します。 & & 参照 が所有 ポインター 参照はポインター 簡単に言えば、Rust では、ある値への参照を作成することを、値を借用することと呼び、最終的にはその所有者に返さなければなりません。 以下の簡単な例を見てみましょう。 let x = 5; let y = &x; println!("Value y={}", y); println!("Address of y={:p}", y); println!("Deref of y={}", *y); 上記により、次の出力が生成されます。 Value y=5 Address of y=0x7fff6c0f131c Deref of y=5 ここで、 変数は変数 する数値を しますが、 は引き続き値を所有します。 を への参照と呼びます。借用は がスコープ外になると終了し、 は値を所有していないため、値は破棄されません。値を借用するには、 演算子で参照します。 p フォーマット は、16 進数で表されるメモリ位置として出力されます。 y x が所有 借用 x y x y y & {:p} 上記のコードで、"*" (つまり、アスタリスク) は、参照変数を操作する逆参照演算子です。この逆参照演算子を使用すると、ポインターのメモリ アドレスに格納されている値を取得できます。 関数が借用によって所有権を取得せずに値を使用する方法を見てみましょう。 fn main() { let v = vec![10,20,30]; print_vector(&v); println!("{}", v[0]); // can access v here as references can't move the value } fn print_vector(x: &Vec ) { println!("Inside print_vector function {:?}", x); } 所有権を譲渡する (つまり、 ) のではなく、参照 ( ) (別名 ) を 関数に渡します。その結果、main 関数で 関数を呼び出した後、 にアクセスできます。 値渡し &v pass-by-reference print_vector print_vector v 逆参照演算子を使用して値へのポインターをたどる 前述のように、参照は一種のポインターであり、ポインターは別の場所に格納されている値を指す矢印と考えることができます。以下の例を考えてみましょう: let x = 5; let y = &x; assert_eq!(5, x); assert_eq!(5, *y); 上記のコードでは、 型の値への参照を作成し、逆参照演算子を使用してデータへの参照に従います。変数 は、 型の値 を保持します。 を への参照に等しく設定します。 i32 x i32 5 y x スタック メモリは次のように表示されます。 は に等しいと断言できます。ただし、 の値に対してアサーションを行いたい場合は、 を使用して参照している値への参照に従う必要があります (したがって、ここでは逆参照)。 を逆参照すると、 が指している整数値にアクセスでき、これを と比較できます。 x 5 y *y y y 5 と書こうとすると、代わりに、次のコンパイル エラーが発生します。 assert_eq!(5, y); error[E0277]: can't compare `{integer}` with `&{integer}` --> src/main.rs:11:5 | 11 | assert_eq!(5, y); | ^^^^^^^^^^^^^^^^ no implementation for `{integer} == &{integer}` これらは型が異なるため、数値と数値への参照を比較することはできません。したがって、逆参照演算子を使用して、それが指している値への参照をたどる必要があります。 参照はデフォルトで不変 変数と同様に、参照はデフォルトで不変です — で変更可能にできますが、その所有者も変更可能である場合に限ります: mut let mut x = 5; let y = &mut x; 不変参照は共有参照とも呼ばれ、可変参照は排他的参照とも呼ばれます。 以下のケースを考えてみましょう。 の代わりに 演算子を使用しているため、参照への読み取り専用アクセスを許可しています。ソース が変更可能であっても、 と は読み取り専用の n 借用であるため、変更できません。 &mut & n ref_to_n another_ref_to_n let mut n = 10; let ref_to_n = &n; let another_ref_to_n = &n; 借用チェッカーは以下のエラーを出します: error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable --> src/main.rs:4:9 | 3 | let x = 5; | - help: consider changing this to be mutable: `mut x` 4 | let y = &mut x; | ^^^^^^ cannot borrow as mutable 貸出ルール なぜ が常に よりも優先されるとは限らないのか疑問に思うかもしれません.もしそうなら、なぜ Rust は セマンティックを持っているのですか? また、デフォルトで しないのはなぜですか?その理由は、Rust で値を借用することが常に可能であるとは限らないためです。貸出は、特定の場合にのみ許可されます。 借用 移動 ムーブ 借用 借用には独自のルール セットがあり、 がコンパイル時に厳密に適用します。これらのルールは、 を防ぐために導入されました。それらは次のとおりです。 借用チェッカー データ競合 借用者の範囲は、元の所有者の範囲を超えることはできません。 複数の不変参照が存在する可能性がありますが、可変参照は 1 つだけです。 所有者は不変参照または可変参照を持つことができますが、両方を同時に持つことはできません。 すべての参照は有効である必要があります (null にすることはできません)。 参照は所有者より長生きしてはなりません 参照のスコープは、値の所有者のスコープ内に含まれている必要があります。そうしないと、参照が解放された値を参照し、 エラーが発生する可能性があります。 use-after-free let x; { let y = 0; x = &y; } println!("{}", x); 上記のプログラムは、所有者 がスコープ外になった後に を逆参照しようとします。 Rust は、この エラーを防ぎます。 y x use-after-free 多くの不変参照、ただし許可される可変参照は 1 つだけ 一度に特定のデータへの不変参照 (別名共有参照) をいくつでも持つことができますが、一度に許可される可変参照 (別名排他的参照) は 1 つだけです。このルールは、 を排除するために存在します。 2 つの参照が同時に同じメモリ位置を指し、そのうちの少なくとも 1 つが書き込み中であり、それらのアクションが同期されて 場合、これはデータ競合として知られています。 データ競合 いない 不変参照はデータを変更しないため、好きなだけ多くの不変参照を使用できます。一方、借用は、コンパイル時のデータ競合の可能性を防ぐために、一度に 1 つの変更可能な参照 ( ) のみを保持するように制限します。 &mut これを見てみましょう： fn main() { let mut s = String::from("hello"); let r1 = &mut s; let r2 = &mut s; println!("{}, {}", r1, r2); } への 2 つの変更可能な参照 ( と ) を作成しようとする上記のコードは失敗します。 s r1 r2 error[E0499]: cannot borrow `s` as mutable more than once at a time --> src/main.rs:6:14 | 5 | let r1 = &mut s; | ------ first mutable borrow occurs here 6 | let r2 = &mut s; | ^^^^^^ second mutable borrow occurs here 7 | 8 | println!("{}, {}", r1, r2); | -- first borrow later used here 閉会の辞 うまくいけば、これで所有権と借用の概念が明確になります。また、所有と借用のバックボーンである借用チェッカーについても簡単に触れました。最初に述べたように、所有権は経験豊富な開発者でも最初は理解するのが難しいかもしれない斬新なアイデアですが、取り組むほど簡単になります。これは、Rust でメモリの安全性がどのように強化されるかを簡単に説明したものです。概念を理解するのに十分な情報を提供しながら、この投稿をできるだけ理解しやすいものにしようとしました。 Rust の所有権機能の詳細については、Rust のオンライン を参照してください。 ドキュメント Rust は、パフォーマンスが重要な場合に最適な選択肢であり、他の多くの言語を悩ませている問題点を解決するため、急な学習曲線を伴う重要な一歩を踏み出します。 であり、Rust を使用する機会があった多くの人々が Rust に恋をしたことを意味します。 Rust コミュニティは成長を続けています。 Rust は 6 年連続で Stack Overflow で最も愛されている言語 : 2021 年は、間違いなく Rust の歴史の中で最も重要な年でした。 Rust Foundation の設立、2021 年版、そしてこれまで以上に大きなコミュニティが見られました。 Rust は、将来に向けて力強い道を進んでいるように見えます。 Rust Survey 2021 結果によると ハッピーラーニング！