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

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

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

Re[2]: g.Dispose();のコードについて [1]


(過去ログ 39 を表示中)

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

■20677 / inTopicNo.21)  Re[9]: g.Dispose();のコードについて
  
□投稿者/ じゅで (51回)-(2008/06/13(Fri) 16:30:17)
2008/06/13(Fri) 16:32:27 編集(投稿者)

No20670 (επιστημη さん) に返信
> ちょちょちょちょい待ち。
> No20662 の認識が真か偽か(偽ならばそれはドコで正しくはどぉか)
> をまず答えてくれませんかのぅ > しってるひと
>

一部調べた結果です。

-ファイナライザはGCに伴って呼び出される。

とありますが、大きく間違っては居ませんが、呼び出されない事もあるようです。
http://msdn.microsoft.com/ja-jp/library/fs2xkftw(VS.80).aspx
http://msdn.microsoft.com/ja-jp/library/system.gc.suppressfinalize(VS.80).aspx

明示的にDisposeされた時ですが、気になるのが、Finalize メソッドの実行は、パフォーマンスに影響を与えることを覚えておいてください。ですかね。
ほっといてGCに任せるのが良いのか・・・

また出てきたら、おしらせします。
間違ってたらごめんなさいorz
引用返信 編集キー/
■20680 / inTopicNo.22)  Re[6]: g.Dispose();のコードについて
□投稿者/ れい (657回)-(2008/06/13(Fri) 16:41:29)
2008/06/13(Fri) 16:42:29 編集(投稿者)

No20662 (επιστημη さん) に返信
> ごめん、僕もきっちりとは理解できてないポいので確認させて。
>
> -Dispose()は要は後始末。絵筆を洗って返却する、みたいな。
> -で、絵筆のストックは有限だから返さないままほっといたらみんなが迷惑する。
> -なのでファイナライザ中に後始末処理が埋め込まれている。
> -ファイナライザはGCに伴って呼び出される。
> -だからDisposeせずにほっといてもいつか(GC時)はDisposeされる。
> -ところが困ったことに、そのいつか(=GC時)が訪れる前に絵筆が枯渇する恐れがある。
> -加えてDiposeされる順番は取得した順(or逆順)とは限らない。後始末の順序は制御不能。
> -だから使い終わったら可及的速やかにDisposeしなければならない。
> -おまけ:using使うとスコープ外れるとき勝手にDisposeしてくれっから楽よ♪
>
> この認識でおk?

微妙に用語が正確でないけどOKなのでは。

> -だからDisposeせずにほっといてもいつか(GC時)はDisposeされる。
->だからDisposeせずにほっといてもいつか(GC時)はファイナライザが呼ばれる。

> -加えてDiposeされる順番は取得した順(or逆順)とは限らない。後始末の順序は制御不能。
->加えてファイナライザの呼び出される順番は取得した順(or逆順)とは限らない。後始末の順序は制御不能。

+Disposeされた後無駄にファイナライザが呼ばれないようにSuppressFinalizeがある
+普通はファイナライザからDisposeが呼ばれるようになっている。
+その辺の標準的コーディングパターンは「Dispose Finalize パターン」あたりを参照

引用返信 編集キー/
■20682 / inTopicNo.23)  Re[9]: g.Dispose();のコードについて
□投稿者/ επιστημη (1092回)-(2008/06/13(Fri) 16:57:16)
επιστημη さんの Web サイト
おおむね間違っちゃいないのね♪ ありがとです。
引用返信 編集キー/
■20685 / inTopicNo.24)  Re[10]: g.Dispose();のコードについて
□投稿者/ シャノン (473回)-(2008/06/13(Fri) 17:06:51)
No20682 (επιστημη さん) に返信
> おおむね間違っちゃいないのね♪ ありがとです。

マネージリソースをほとんど消費せず、アンマネージリソースばかりバカ食いするアプリの場合、いつまでたっても GC が発動しないで、プロセス終了まで解放されないリソースを抱え込むことになったりします。

あとは、CriticalFinalizerObject なんかが絡むと事態はさらにややこしくなりますが、それはまた別の機会に。
引用返信 編集キー/
■20686 / inTopicNo.25)  Re[10]: g.Dispose();のコードについて
□投稿者/ じゅで (52回)-(2008/06/13(Fri) 17:10:56)
No20682 (επιστημη さん) に返信
> おおむね間違っちゃいないのね♪ ありがとです。

プラスアルファで、GCの処理ただでさえ重いから、
Finalize メソッドの実行は、パフォーマンスに影響を与えるので、出来る限り明示的につど開放して下さい。

みたいな事を考えていたんですが、あまり関係なさげですか。
間抜けですいませんorz

# 余談

次に示す状況では、Finalize メソッドが完了しないことや、このメソッドがまったく実行されないことがあります。

別のファイナライザが無期限にブロックしている。たとえば、無限にループしているか、取得不可能なロックを取得しようとしている場合など。ランタイムが完了処理のためにファイナライザを実行しようとしているため、ファイナライザが無期限にブロックしている場合には、他のファイナライザが呼び出されません。

ランタイムがクリーンアップを実行する前に、プロセスが終了した。この場合、プロセス終了をランタイムへ伝える最初の通知は DLL_PROCESS_DETACH 通知です。

> ->加えてファイナライザの呼び出される順番は取得した順(or逆順)とは限らない。後始末の順序は制御不能。

とかがあるので、明示的に開放しなさいと言う事だと調べながら考えておりました。orz

http://msdn.microsoft.com/ja-jp/library/system.object.finalize(VS.80).aspx
引用返信 編集キー/
■20687 / inTopicNo.26)  Re[6]: g.Dispose();のコードについて
□投稿者/ 渋木宏明(ひどり) (783回)-(2008/06/13(Fri) 17:12:19)
渋木宏明(ひどり) さんの Web サイト
> -加えてDiposeされる順番は取得した順(or逆順)とは限らない。後始末の順序は制御不能。

順番が制御不能であることによって不都合を生じるかどうかは、カプセルされているアンマネージリソースが「どんなものか」に依存します。

> ほっといてGCに任せるのが良いのか・・・

放っておいて問題がないかどうかも、カプセルされているアンマネージリソースが「どんなものか」に依存します。

ですが、一般的にリソースの使用は最小限度にとどめておくのが吉であるため、不要なリソースは速やかに解放するべきです。

>それとも「GC」はメモリ以外のリソースについても管理し、「GC」が
>走るのでしょうか?

いいえ。GC はマネージヒープから取得されたメモリしか管理しません。

だからこそ、うっちゃらかしになったアンマネージリソースの後始末をするべき「ファイナライザで Dispose() 呼び出しを行うこと」という規約があるのです。

>システムリソースとかですかね?

などなどですね。これも、カプセルされているアンマネージリソースが「どんなものか」次第です。

>けどよくよく考えると、いくらGCはしるといっても、ヒープ領域しかみてないなら、
>GCはしんべやっていってほっといたら、GDIとかのシステムリソース先に食いつぶしそうですが。

GC がクラスインスタンスを解放する直前にファイナライザを呼び出し、ファイナライザ内で Dispose() 呼び出しが行われることによって、GC によってクラスインスタンスが解放されるのと同期して、クラスインスタンがカプセルするアンマネージリソースの解放が行われます。


引用返信 編集キー/
■20688 / inTopicNo.27)  Re[10]: g.Dispose();のコードについて
□投稿者/ れい (658回)-(2008/06/13(Fri) 17:13:45)
2008/06/13(Fri) 17:16:21 編集(投稿者)

No20682 (επιστημη さん) に返信
> おおむね間違っちゃいないのね♪ ありがとです。

俺を信じると火傷するぜ…?

一回言ってみたかった。
シチュエーションが違う気がしますが。

つわけで、正しい答えは引き続き募集中>>偉い人

No20666 (じゅで さん) に返信
>>ただ、宇宙仮面様のページを見て思ったんですけど、
>>「画像系ってメモリ以外の資源は気にしなくていいんだ。」
>>って思いました。もし、メモリ以外のリソースを使っているなら、
>>メモリ枯渇で「GC」する前に、他のリソースが枯渇してしまうのだから、
>>「GC」に頼ることは出来ないはずですし。
>>(明示的なDisposeを期待するオブジェクトは全てメモリ以外の
>>リソースを使用している可能性があるのだと思っていました)
>>
>>それとも「GC」はメモリ以外のリソースについても管理し、「GC」が
>>走るのでしょうか?
>>
>
> システムリソースとかですかね?
> けどよくよく考えると、いくらGCはしるといっても、ヒープ領域しかみてないなら、
> GCはしんべやっていってほっといたら、GDIとかのシステムリソース先に食いつぶしそうですが。

何の話かよくわからないのですが、
メモリ((マネージド)ヒープ)に関しての話と、
それ以外のアンマネージドな、もしくは明示的に廃棄せねばならないリソースに関する話と、
混乱してるとよく理解できないかと。

GCは元々CLRが割り当てたヒープを解放するためにあって、
そのときまだSuppressFinalizeが呼ばれてなければついでにファイナライザを呼んでくれる、
と解釈するといいのかなぁと思っています。

追記。

あー。
皆さんがいろいろ投稿してますね。
私のは無視していただければ。
引用返信 編集キー/
■20689 / inTopicNo.28)  Re[10]: g.Dispose();のコードについて
□投稿者/ 渋木宏明(ひどり) (784回)-(2008/06/13(Fri) 17:17:59)
渋木宏明(ひどり) さんの Web サイト
> おおむね間違っちゃいないのね♪ ありがとです。

デストラクタ呼び出しとインスタンスメモリの解放が分離されている、って考えると分かりやすいんじゃないですか?

GC 配下ではインスタンスメモリの解放を明示的に行うことができないので、インスタンスがカプセルしているアンマネージリソースを解放するための手続きが別途必要である、と。

引用返信 編集キー/
■20690 / inTopicNo.29)  Re[11]: g.Dispose();のコードについて
□投稿者/ じゅで (53回)-(2008/06/13(Fri) 17:21:22)
2008/06/13(Fri) 17:22:32 編集(投稿者)

No20688 (れい さん) に返信
> GCは元々CLRが割り当てたヒープを解放するためにあって、
> そのときまだSuppressFinalizeが呼ばれてなければついでにファイナライザを呼んでくれる、
> と解釈するといいのかなぁと思っています。

これは、ヒープのメモリ領域によって、GCの処理が開始されるのであれば、
システムリソースを抑えているものに対しては、明示的に開放をしてあげないと、
GC任せにしてると、もしかしたら大変な事になるかな?

と言う事です。

GCがヒープ以外のシステムリソースまで見て、実行されるなら、ファイナライザ呼ばれるから、
ほっといても良いものがあるでしょうが。

追記

>>それとも「GC」はメモリ以外のリソースについても管理し、「GC」が
>>走るのでしょうか?

>いいえ。GC はマネージヒープから取得されたメモリしか管理しません。

>だからこそ、うっちゃらかしになったアンマネージリソースの後始末をするべき「ファイナライ>ザで Dispose() 呼び出しを行うこと」という規約があるのです。

やっぱそうですよね。
引用返信 編集キー/
■20691 / inTopicNo.30)  Re[1]: g.Dispose();のコードについて
□投稿者/ Z (20回)-(2008/06/13(Fri) 17:21:38)
No20643 (初心VC#2008 さん) に返信
> 初心者の極めてしょぼい質問ですがよろしくお願いします。
>
> 画像オブジェクトを作成して、そこに描画してからリソースを解放するということで
> g.Dispose();のコードを書くようになっていますが、
> これは、メモリを解放するための処理と書かれてあったのですが、画像を削除するという
> ことではないのですよね。(画像が消えないのでもちろんそう思いますが)
>
> では、g.Dispose();を記述しない場合はどのような不都合が生じるのでしょうか?
> (メモリ不足になるのでしょうか。)
>
> これはいわゆるC#の約束事と理解してよろしいのでしょうか?
> ちなみにリソースを自動的に解放してくれる言語はあるのでしょうか?
>
引用返信 編集キー/
■20694 / inTopicNo.31)  Re[1]: g.Dispose();のコードについて
□投稿者/ Z (21回)-(2008/06/13(Fri) 17:29:02)
No20643 (初心VC#2008 さん) に返信
> 初心者の極めてしょぼい質問ですがよろしくお願いします。
>
> 画像オブジェクトを作成して、そこに描画してからリソースを解放するということで
> g.Dispose();のコードを書くようになっていますが、
> これは、メモリを解放するための処理と書かれてあったのですが、画像を削除するという
> ことではないのですよね。(画像が消えないのでもちろんそう思いますが)
>
> では、g.Dispose();を記述しない場合はどのような不都合が生じるのでしょうか?
> (メモリ不足になるのでしょうか。)
>
> これはいわゆるC#の約束事と理解してよろしいのでしょうか?
> ちなみにリソースを自動的に解放してくれる言語はあるのでしょうか?
>

すいません、自分が相乗りしたせいもあり、いろいろと広がってしまった気がします。

トピ主さんの最初の質問の回答として、

@ これはいわゆるC#の約束事と理解してよろしいのでしょうか?
「g.Disposeを書かないと、何らかの不都合が起こることがある。不都合の内容は使用しているリソースによる。」

でよろしいでしょうか?

Aちなみにリソースを自動的に解放してくれる言語はあるのでしょうか?

こちらについては、有識者の方、お願いします。D言語とかJAVAとかもGCはありますが、「Dispose」や
「Close」等の明示的な破棄が必要ない言語ってあるのですかね?。




引用返信 編集キー/
■20697 / inTopicNo.32)  Re[2]: g.Dispose();のコードについて
□投稿者/ シャノン (474回)-(2008/06/13(Fri) 17:39:59)
No20694 (Z さん) に返信
> @ これはいわゆるC#の約束事と理解してよろしいのでしょうか?
> 「g.Disposeを書かないと、何らかの不都合が起こることがある。不都合の内容は使用しているリソースによる。」
>
> でよろしいでしょうか?

Yes。

> Aちなみにリソースを自動的に解放してくれる言語はあるのでしょうか?
>
> こちらについては、有識者の方、お願いします。D言語とかJAVAとかもGCはありますが、「Dispose」や
> 「Close」等の明示的な破棄が必要ない言語ってあるのですかね?。

C++/CLIとかw
引用返信 編集キー/
■20705 / inTopicNo.33)  Re[3]: g.Dispose();のコードについて
□投稿者/ επιστημη (1096回)-(2008/06/13(Fri) 18:07:55)
επιστημη さんの Web サイト
>> 「Dispose」や「Close」等の明示的な破棄が必要ない言語ってあるのですかね?。
>
> C++/CLIとかw

ぉぅぃぇーwww

引用返信 編集キー/
■20707 / inTopicNo.34)  Re[2]: g.Dispose();のコードについて
□投稿者/ ネタ好き (442回)-(2008/06/13(Fri) 18:10:52)
>Aちなみにリソースを自動的に解放してくれる言語はあるのでしょうか?

やっぱりLispでしょう。
引用返信 編集キー/
■20712 / inTopicNo.35)  Re[12]: g.Dispose();のコードについて
□投稿者/ 渋木宏明(ひどり) (785回)-(2008/06/13(Fri) 19:07:58)
渋木宏明(ひどり) さんの Web サイト
> >いいえ。GC はマネージヒープから取得されたメモリしか管理しません。
>
> >だからこそ、うっちゃらかしになったアンマネージリソースの後始末をするべき「ファイナライ>ザで Dispose() 呼び出しを行うこと」という規約があるのです。
>
> やっぱそうですよね。

.NET 2.0 で GC.AddMemoryPressure() が追加されていたりするので、ものすごく厳密に言うと「GC がマネージドヒープ以外のことはまったく考慮していない」とは言えないかもしれません。

ですが、外部から教えてやらない限りは「気づかない」ので、自発的にはまるで考慮していないとみていいでしょう。

引用返信 編集キー/
■20713 / inTopicNo.36)  Re[2]: g.Dispose();のコードについて
□投稿者/ 渋木宏明(ひどり) (786回)-(2008/06/13(Fri) 19:11:07)
渋木宏明(ひどり) さんの Web サイト
> (1) これはいわゆるC#の約束事と理解してよろしいのでしょうか?

「.NET の(あるいは CLR の)」約束事です。

C# だけでなく、VB でも状況は同じです。

ただし、.NET 上で動作するものであっても、言語処理系がそれを隠ぺいする可能性はあり得ます。


引用返信 編集キー/
■20717 / inTopicNo.37)  Re[13]: g.Dispose();のコードについて
□投稿者/ じゅで (55回)-(2008/06/13(Fri) 20:28:20)
No20712 (渋木宏明(ひどり) さん) に返信
> .NET 2.0 で GC.AddMemoryPressure() が追加されていたりするので、ものすごく厳密に言うと「GC がマネージドヒープ以外のことはまったく考慮していない」とは言えないかもしれません。
>
> ですが、外部から教えてやらない限りは「気づかない」ので、自発的にはまるで考慮していないとみていいでしょう。

あっ。
これは、すごく勉強になりました。
ありがとうございます。

URLの貼り付け。

http://msdn.microsoft.com/ja-jp/library/system.gc.addmemorypressure(VS.80).aspx


引用返信 編集キー/

<前の20件
トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ

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

管理者用

- Child Tree -