C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

メモリの解放について

(過去ログ 8 を表示中)

[トピック内 20 記事 (1 - 20 表示)]　 << 0 >>

■8306 / inTopicNo.1)

　メモリの解放について

▼■

□投稿者/ 初心者A 二等兵(1回)-(2006/11/15(Wed) 16:40:17)

分類:[C#]　

分類:[C#]　

超初心者で的外れな質問かも知れませんが回答よろしくお願いします。

メモリの解放についてです。

newしたオブジェクトのメモリ解放は、どのようにコーディングすればよろしいのでしょうか？

コアライブラリであるStreamReaderのオブジェクトはcloseメソッドがあるので、解放はできますが、例えば自分で作成したクラスのオブジェクトを解放するためにはどのようにすればよいでしょうか？

ガベージコレクションというのは、メモリが不足したとき処理が始まるとのことですが、正確にどのような条件によって行われるのでしょうか？

以上よろしくお願いいたします。

引用返信 編集キー/

■8308 / inTopicNo.2)

　Re[1]: メモリの解放について

▲▼■

□投稿者/ はいこーん中尉(140回)-(2006/11/15(Wed) 17:08:33)

分類:[C#]　

メモリとアンマネージリソースを同一視している人って多いよね。

引用返信 編集キー/

■8313 / inTopicNo.3)

　Re[2]: メモリの解放について

▲▼■

□投稿者/ 初心者A 二等兵(3回)-(2006/11/15(Wed) 18:15:24)

分類:[C#]　

■No8308に返信(はいこーんさんの記事)
> メモリとアンマネージリソースを同一視している人って多いよね。

アドバイスありがとうございます。そもそもアンマネジリソースという用語自体知りませんでした。
つまり、リソースには「マネジリソース」と「アンマネジリソース」の2種類があるということですね。

それで、データベースコネクションやファイルハンドルなどは、「アンマネジリソース」郡に含まれるため、明示的に解放しなければならない。

では、自分で作成したクラスのインスタンスは「マネジリソース」郡に入る。こういう認識でよろしいのでしょうか？

だとしたら、「マネジリソース」はいつ、どのような条件でガベージコレクタがメモリを解放してくれるでしょうか？

明示的には無理なのでしょうか？

回答お願いします。

引用返信 編集キー/

■8319 / inTopicNo.4)

　Re[3]: メモリの解放について

▲▼■

□投稿者/ 中博俊神(842回)-(2006/11/15(Wed) 20:16:54)

分類:[C#]　

とりあえず一言で言えないので、書籍かなんかで勉強しませんか？
キーワードはガベージコレクション、GCです。

がんばってください。

引用返信 編集キー/

■8324 / inTopicNo.5)

　Re[3]: メモリの解放について

▲▼■

□投稿者/ 渋木宏明(ひどり) 一等兵(37回)-(2006/11/15(Wed) 21:51:41)

分類:[C#]　

> それで、データベースコネクションやファイルハンドルなどは、「アンマネジリソース」郡に含まれるため、明示的に解放しなければならない。

そうです。でもそれは、クラス実装によって隠蔽されているべき。

「アンマネージリソースを解放するために Close() を呼び出す」なんて考えるのはおかしくて、「Open() したものは使い終わったら Close() する（のが、このクラスの使い方」と捉えるのが自然だと思います。

> では、自分で作成したクラスのインスタンスは「マネジリソース」郡に入る。こういう認識でよろしいのでしょうか？

そうです。

> だとしたら、「マネジリソース」はいつ、どのような条件でガベージコレクタがメモリを解放してくれるでしょうか？

ガベージコレクタの設計と設定次第です。

> 明示的には無理なのでしょうか？

GC.Collect() でハッパをかけることはできますが、それ以上は無理です。

引用返信 編集キー/

■8326 / inTopicNo.6)

　Re[4]: メモリの解放について

▲▼■

□投稿者/ 田中二等兵(19回)-(2006/11/15(Wed) 23:57:44)

分類:[C#]　

GCに関しては宇宙仮面様のサイトが参考になるのではと思います。
http://uchukamen.com/Programming/GC/index.htm

引用返信 編集キー/

■8329 / inTopicNo.7)

　Re[5]: メモリの解放について

▲▼■

□投稿者/ 初心者A 二等兵(4回)-(2006/11/16(Thu) 08:41:56)

分類:[C#]　

>>中博俊さま
レスありがとうございます。キーワードさえわかれば、いろいろと調べられますね。

>>渋木宏明(ひどり)さま
明確かつ具体的な回答ありがとうございます。一つ一つの疑問に対応するような形式での回答なので、明確に調べるべき内容がわかりました。

>>田中さま
そこのサイトは一度拝見しましたが、今度は詳細に調べてゆきたいと思います。レスありがとうございます。

引用返信 編集キー/

■8418 / inTopicNo.8)

　Re[6]: メモリの解放について

▲▼■

□投稿者/ ハロルド二等兵(1回)-(2006/11/20(Mon) 20:21:01)

分類:[C#]　

質問内容から察するに、newしたオブジェクトのメモリを
不必要になったら即座に破棄したいという事だと思いますが、
ここで一度、GCについてよく考えるべきだと思います。

そもそも、何のためにGCがあるのか・・・

それは、限られたPCのパフォーマンスをより効率よく使用するためです。
即座にメモリを破棄するという事は、ソフトウェアの作者からすると、
直感的で理解しやすいと思いますが、でも、そんなことはどうでもいいのです。
使う側がより快適に使える事のほうが重要なのです。

メモリの開放は、何も今すぐしなくてはいけないような処理では決してないはずです。
そのような処理は、GCの判断に任せて設計するべきだと思います。

引用返信 編集キー/

■8449 / inTopicNo.9)

　Re[7]: メモリの解放について

▲▼■

□投稿者/ れんげ二等兵(4回)-(2006/11/21(Tue) 22:48:23)

分類:[C#]　

>>ハロルド様
上記、田中様も書かれましたが、再掲。
http://uchukamen.com/Programming/GC/index.htm
ここを読めばメモリの開放を考える理由はよくわかるかと。
今でも使い終わったリソースをすぐに開放することは
一般的に有用と言われています。

ちなみに昔はＧＣなど当然なかったのでリソースの開放はプログラマーが
明示的に行うのが当たり前でした。（でないとえらいことに。。

古い人間からすればちゃんと開放しないと気持ち悪い‥、
そんな気持ちがわからんでもないですねぇ。。。

引用返信 編集キー/

■8462 / inTopicNo.10)

　Re[8]: メモリの解放について

▲▼■

□投稿者/ 中博俊神(850回)-(2006/11/22(Wed) 15:43:54)

分類:[C#]　

>ちなみに昔はＧＣなど当然なかったのでリソースの開放はプログラマーが
>明示的に行うのが当たり前でした。（でないとえらいことに。。
>古い人間からすればちゃんと開放しないと気持ち悪い‥、
>そんな気持ちがわからんでもないですねぇ。。。

そんなことはありません。
ガベージコレクション方式も、参照カウント方式も、プログラムのアロケート/Free方式も太古からある管理方式の一つです。
BASICも昔からガベージコレクション方式だったりしませんか？

引用返信 編集キー/

■8463 / inTopicNo.11)

　Re[9]: メモリの解放について

▲▼■

□投稿者/ επιστημη 大将(287回)-(2006/11/22(Wed) 16:00:21)

分類:[C#]　

> BASICも昔からガベージコレクション方式だったりしませんか？

なつかちー!

メモリ喰って喰って喰いまくって、もう残りわずかになるや
本業そっちのけでゴミ掃除を始めるもんだからアプリが
'かちーん' と固まりましたとも (^^

# PC-8001, N-Basic でのオハナシです。

引用返信 編集キー/

■8471 / inTopicNo.12)

　Re[10]: メモリの解放について

▲▼■

□投稿者/ とっちゃん伍長(48回)-(2006/11/22(Wed) 17:25:50)

分類:[C#]　

■No8463に返信(επιστημηさんの記事)
> メモリ喰って喰って喰いまくって、もう残りわずかになるや
> 本業そっちのけでゴミ掃除を始めるもんだからアプリが
> 'かちーん' と固まりましたとも (^^
>
> # PC-8001, N-Basic でのオハナシです。
>
8801もおなじっすｗ

#これがあったから、短期でBASICでプログラムかけたんですものｗ

引用返信 編集キー/

■8481 / inTopicNo.13)

　Re[11]: メモリの解放について

▲▼■

□投稿者/ 中博俊神(851回)-(2006/11/22(Wed) 23:48:06)

分類:[C#]　

あの時代のGCは停止ですからねー(^^

引用返信 編集キー/

■8486 / inTopicNo.14)

　Re[12]: メモリの解放について

▲▼■

□投稿者/ はつね二等兵(2回)-(2006/11/23(Thu) 10:21:55)

分類:[C#]　

■No8481に返信(中博俊さんの記事)
> あの時代のGCは停止ですからねー(^^

どうもその記憶が強烈過ぎて、GCは、忘れたときのためのフェイルセーフのような位置づけと考えてしまい、()のペアのように明示的に破棄する方法を採用しています。

VB2005だと、Using～End Using使って、Usingで指定した変数がEnd UsingでDisposeしてくれるのがお気に入りだったりします。

引用返信 編集キー/

■8489 / inTopicNo.15)

　Re[13]: メモリの解放について

▲▼■

□投稿者/ 渋木宏明(ひどり) 一等兵(39回)-(2006/11/23(Thu) 14:00:58)

分類:[C#]　

> VB2005だと、Using～End Using使って、Usingで指定した変数がEnd UsingでDisposeしてくれるのがお気に入りだったりします。

残念ですが、大きな勘違いをしています。

Dispose() によって解放されるのはクラスインスタンスが内包するアンマネージリソースであって、クラスインスタンスが消費している（マネージドな）メモリではありません。

引用返信 編集キー/

■8490 / inTopicNo.16)

　Re[14]: メモリの解放について

▲▼■

□投稿者/ 渋木宏明(ひどり) 伍長(40回)-(2006/11/23(Thu) 14:03:31)

分類:[C#]　

クラスインスタンスが消費しているマネージドなメモリは、GC によってのみ解放されます。

引用返信 編集キー/

■8491 / inTopicNo.17)

　Re[15]: メモリの解放について

▲▼■

□投稿者/ はつね二等兵(3回)-(2006/11/23(Thu) 15:13:22)

分類:[C#]　

■No8490に返信(渋木宏明(ひどり)さんの記事)
> クラスインスタンスが消費しているマネージドなメモリは、GC によってのみ解放されます。

End UsingでDisposeされるのは間違えていなかったようですが、Disposeで解放させるものをきちんと理解していないかったのか。。。。

そうすると、任意のタイミングでマネージドなメモリを開放するには、
System.GC.Collect()
を使う以外にはない？
# hogehoge = Nothing としても駄目なんですよね？

引用返信 編集キー/

■8493 / inTopicNo.18)

　Re[16]: メモリの解放について

▲▼■

□投稿者/ 囚人伍長(46回)-(2006/11/23(Thu) 19:06:15)

分類:[C#]　

>System.GC.Collect()

急かす事はできるでしょうけど、あまりよくないですよね。

># hogehoge = Nothing としても駄目なんですよね？

ダメですね。参照が幾分はやく外れるから、ほんのちょっぴり早くガベージコレクションの対象になるかもしれませんが。

引用返信 編集キー/

■8494 / inTopicNo.19)

　Re[17]: メモリの解放について

▲▼■

□投稿者/ はつね二等兵(4回)-(2006/11/23(Thu) 19:41:10)

分類:[C#]　

「アンマネージドなメモリ領域を明示的に解放し、マネージドなメモリ領域はGCに任せる」と知識をリプレースする事といたします。
アンマネージドという言葉の響きのものを解放できるだけでもＯＫとしよう。

引用返信 編集キー/

■8502 / inTopicNo.20)

　Re[18]: メモリの解放について

▲　■

□投稿者/ 渋木宏明(ひどり) 伍長(41回)-(2006/11/24(Fri) 07:47:54)

分類:[C#]　

> 「アンマネージドなメモリ領域を明示的に解放し、

アンマネージなのはメモリだけではありません。

「ＯＳ等の下位レイヤが使う作業域」という意味では最終的にメモリも含まれますが、.NET レベルの視点で見ると、ほとんどの場合がハンドルです。

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -