それをクローンしたりそれがスコープから外れたりする度に参照カウントを増減するための計算コストが掛かります。コピーを返すだけだということに注意しましょう。内的ミュータビリティを提供します。参照先であるとき)、操作できるデータを持つということです。cellモジュールのドキュメントには、それらについての非常によい説明があります。構造体のフィールドで見られますが、他の場所でも見られるかもしれません。型のためだけのものです。コンパイラは含まれている値によって所有されている全てのデータがスタック上にあることを認識しています。そのため、単純にデータが置き換えられることによって参照先のデータがメモリリークを起こす(又はもっと悪いことも!)心配はありません。このラッパを使うことで、維持されている不変性に違反してしまう可能性もあるので、それを使うときには注意しましょう。ラップされているならば、そのデータの塊はミュータブルで、最初にそれを読み込んだときとそれを使おうと思ったときで同じままだとは限らないということのよい目印になります。x.get());ここでは同じ値を様々なイミュータブルな参照から変更できるということに注意しましょう。これには次のものと同じ実行時のコストが掛かります。x);しかし、それには実際に正常にコンパイルできるという追加の利点があります。保証これは「ミュータブルなエイリアスはない」という制約を、それが不要な場所において緩和します。これはその制約が提供する保証をも緩和してしまいます。保存されているデータに依存しているのであれば、注意すべきです。型を変更するのに便利です。よって安全な方法で自由に変更できるようなデータへの内部の参照を得られるわけではありません。使用に実行時のコストは掛かりません。ラップする方がよいかもしれません。しなければ、各書込みが構造体の完全コピーを発生させることになるからです。その代わり、それには実行時のコストが掛かります。読み書きロックパターンを実行時に(シングルスレッドのミューテックスのように)強制します。関数によって行われます。それらは内部の参照カウントを変更し、それぞれイミュータブル、ミュータブルに参照を外すことのできるスマートポインタを戻します。参照カウントはスマートポインタがスコープから外れたときに元に戻されます。このシステムによって、ミュータブルな借用が有効なときには決してその他の借用が有効にならないということを動的に保証することができます。プログラマがそのような借用を作ろうとすれば、スレッドはパニックするでしょう。同様に、これは主に、借用チェッカを満足させることが困難、又は不可能な状況で便利です。一般的に、そのような変更はネストした形式では発生しないと考えられますが、それをチェックすることはよいことです。中に入れることは便利です。Rustコンパイラの内部のctxt構造体にあるたくさんのマップはこのラッパの中にあります。それらは(初期化の直後ではなく生成の過程で)一度だけ変更されるか、又はきれいに分離された場所で数回変更されます。ポインタのスープになってしまいます。それらにアクセスするための(ゼロコストではありませんが)低コストの方法です。将来、もし誰かが既に借用されたセルを変更しようとするコードを追加すれば、それは(普通は確定的に)パニックを引き起こすでしょう。これは、その違反した借用まで遡り得ます。同様に、ServoのDOMではたくさんの変更が行われるようになっていて、そのほとんどはDOM型にローカルです。複数のDOMに縦横無尽にまたがり、様々なものを変更するものもあります。起こっている場所を強調してくれます。避けるべきであるということに注意しましょう。そのため、その保証は変わりません。割当てを行いませんが、データとともに(サイズ1ワードの)追加の「借用状態」の表示を持っています。実行時には、各借用が参照カウントの変更又はチェックを発生させます。前に挙げた型の多くはスレッドセーフな方法で使うことができません。参照カウントとは、データ競合を発生させることなく複数のスレッドから増加させることができるもののことです)を使っていて、スレッドセーフな方法で使うことができません。これによってそれらを低コストで使うことができるのですが、それらのスレッドセーフなバージョンも必要です。いう形式で存在します。これはコンパイル時にチェックされます。モジュールには並行プログラミングのための便利なラッパがたくさんありますが、以下では有名なものだけをカバーします。別バージョンです(そのため、「Arc」なのです)。これはスレッド間で自由に送ることができます。似ていますが、C++の場合、中身のデータは常にミュータブルです。ブロックが必要というセル型です)。最後のものは、その使用がメモリをアンセーフにしないことを確信している場合にだけ使うべきです。次のことを覚えましょう。構造体に書き込むのはアトミックな作業ではなく、vec.push()のような多くの関数は内部でメモリの再割当てを行い、アンセーフな挙動を引き起こす可能性があります。正当化するには十分ではありません。スコープから外れたときに(循環がなければ)中身のデータのためのデストラクタが実行されることを(スレッドセーフに)保証します。コストこれには参照カウントの変更(これは、それがクローンされたりスコープから外れたりする度に発生します)にアトミック性を使うための追加のコストが掛かります。ポインタを共有する方が適切です。RAIIガード(ガードとは、ロックのようにそれらのデストラクタが呼び出されるまである状態を保持するオブジェクトのことです)による相互排他を提供します。呼び出すまでミューテックスは不透明です。その時点で、スレッドはロックが得られ、ガードが戻されるまでブロックします。このガードを使うことで、中身のデータに(ミュータブルに)アクセスできるようになり、ロックはガードがスコープから外れたときに解放されます。デストラクタが実行されるときにロックは解除されるRwLockには複数の読込みを効率化するという追加の利点があります。それはライタのない限り常に、共有されたデータに対する複数のリーダを安全に持つことができます。RwLockによってリーダは「読込みロック」を取得できます。このようなロックは並行に取得することができ、参照カウントによって追跡することができます。ライタは「書込みロック」を取得する必要があります。「書込みロック」はすべてのリーダがスコープから外れたときにだけ取得できます。保証それらのどちらもスレッド間での安全で共有されたミュータビリティを提供しますが、それらはデッドロックしがちです。型システムによって、ある程度の追加のプロトコルの安全性を得ることができます。コストそれらはロックを保持するために内部でアトミック的な型を使います。それにはかなりコストが掛かります(それらは仕事が終わるまで、プロセッサ中のメモリ読込み全てをブロックする可能性があります)。たくさんの並行なアクセスが起こる場合には、それらのロックを待つことが遅くなる可能性があります。ような型(又はそのような型のもっと複雑な合成)です。その合成が何をしているのか、なぜ作者はこんなものを選んだのか(そして、自分のコード内でいつこんな合成を使うべきなのか)ということは、常に明らかなわけではありません。普通、それは不要なコストを支払うことなく、必要とする保証を互いに組み合わせた場合です。そのような合成の1つです。そのものはミュータブルに参照を外すことができません。共有を提供し、共有されたミュータビリティはアンセーフな挙動に繋がる可能性があります。これで共有されたミュータブルなデータを持つことになりますが、それは(リーダはなしで)ライタが1つだけ、又はリーダが複数という方法で共有することになります。それらは両方とも共有できるミュータブルなベクタですが、同じではありません。全体がミュータブルです。全体の唯一のミュータブルな借用になり得ます。ハンドルから同時には操作できないということを意味します。対するプッシュやポップは好きなように行うことができます。2つ目について、借用は個々の要素に対して行われますが、ベクタ全体がイミュータブルになります。そのため、異なる要素を別々に借用することができますが、ベクタに対するプッシュやポップを行うことはできません。同じですが、やはり借用チェックは実行時に行われます。似た状況に置かれます。それは共有されたミュータビリティと所有権を提供します。それらを使ったコードを読むときには、1行1行進み、提供される保証とコストを見ましょう。合成された型を選択するときには、その逆に考えなければなりません。必要とする保証が何であるか、必要とする合成がどの点にあるのかを理解しましょう。どちらかを選ぶのであれば、前の方で行ったようにトレードオフを理解し、選ばなければなりません。その要素を変更できますが、その長さは変更することができません。ないため、実際にはコンパイルできません。実装した型でラップすることができます。