タグ付けされた質問 「memory」

メモリとは、コンピュータまたはその他のデジタル電子デバイスで使用するために、プログラムまたはデータを一時的または永続的に格納するために使用される物理デバイスを指します。

2
ソケットと共有メモリを介して行われるプロセス間通信の長所と短所は何ですか?
プロセス間通信の多くのオプションのうち2つは次のようになる可能性があることを理解しています。 共有メモリ ソケット 実際、Javaアプリケーションをデバッグするために、Intellij Ideaがこれら2つのオプションを公開しているのを見ました。それぞれのアプローチの長所と短所を知りたいのですが。

1
Javaでオブジェクト/配列を割り当てるときにオーバーヘッドが発生するのはなぜですか?
Javaで配列が占めるバイト数は?これは64ビットマシンであり、配列にN個の要素があると仮定します。したがって、これらの要素はすべて、異なるタイプの配列に対して2 * N、4 * N、または8 * Nバイトを占めることになります。 また、Courseraでの講義では、N要素配列では2 * N + 24、4 * N + 24、または8 * N + 24バイトを占有し、24バイトはオーバーヘッドと呼ばれますが、オーバーヘッドがなぜであるかは説明されていません必要。 また、オブジェクトには16バイトのオーバーヘッドがあります。 これらのオーバーヘッドは正確には何ですか?これらの24/16バイトは何で構成されていますか? また、これらのオーバーヘッドはJavaにのみ存在しますか?C、C ++、Pythonはどうですか?
9 java  memory 

4
メモリ使用量の分析:JavaとC ++は無視できるか?
Javaで記述された整数オブジェクトのメモリ使用量は、C ++で記述された整数オブジェクトのメモリ使用量とどのように比較されますか?違いは無視できますか?変わりはない?大きな違いは?言語に関係なくintはintであるため、同じだと思います(?) 私がこれを尋ねた理由は、プログラムのメモリ要件がプログラマーが特定の問題を解決するのをいつ妨げるかを知ることの重要性について読んでいたからです。 私を魅了したのは、単一のJavaオブジェクトを作成するために必要なメモリの量です。たとえば、整数オブジェクトを考えてみましょう。私が間違っているが、Java整数オブジェクトが24バイトのメモリを必要とする場合は修正してください。 intインスタンス変数用に4バイト 16バイトのオーバーヘッド(オブジェクトのクラス、ガベージコレクション情報、同期情報への参照) 4バイトのパディング 別の例として、Java配列(オブジェクトとして実装されている)には48バイト以上が必要です。 24バイトのヘッダー情報 16バイトのオブジェクトオーバーヘッド 長さは4バイト パディング用に4バイト さらに、値を格納するために必要なメモリ これらのメモリ使用量は、C ++で記述された同じコードとどのように比較されますか? 以前は自分が書いたC ++およびJavaプログラムのメモリ使用量について気づいていませんでしたが、アルゴリズムについて学び始めた今、コンピューターのリソースに対する理解が深まっています。

3
JVMメモリを適切な方法で監視するにはどうすればよいですか?
忙しい時間帯でも、本番環境でオーバーヘッドの少ない方法でJVMメモリモニターを行う方法を考えています。 本番環境に2つのtomcatアプリサーバーがあり、それらの背後に負荷分散が設定されているとします。jvmメモリー統計を表示できる場合は、OOMの問題が発生するサーバーへのリクエストの送信を停止するようにロードバランスに指示できます。これは理にかなっていますか?JconsoleまたはVisualVMがより多くのパフォーマンスリソースを消費するのは私の選択ではありません。

3
カスタムヒープアロケーター
ほとんどのプログラムは、関数型プログラミング言語が古いオブジェクトを変更するよりも新しいオブジェクトを割り当てることを好み、ガベージコレクターが解放することを心配する程度にまで、ヒープの割り当てについてかなりカジュアルになり得ます。 ただし、組み込みプログラミングのサイレントセクターでは、メモリとリアルタイムの制約により、ヒープ割り当てをまったく使用できないアプリケーションが数多くあります。処理される各タイプのオブジェクトの数は仕様の一部であり、すべてが静的に割り当てられます。 ゲームプログラミング(少なくともハードウェアのプッシュに意欲的なゲームでは)は、その中間になることがあります。動的割り当てを使用できますが、アロケーターをブラックボックスとして処理できない十分なメモリとソフトリアルタイム制約があります、ガベージコレクションはもちろんのこと、カスタムアロケータを使用する必要があります。これが、ゲーム業界でC ++が依然として広く使用されている理由の1つです。http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.htmlのようなことができます その中間の領域には他にどのようなドメインがありますか?ゲームとは別に、カスタムアロケーターが頻繁に使用されていますか?

2
なぜDateTime.Monthがintなのですか?
C#では、DateTimeプロパティMonthのタイプはint(32ビットの符号付き整数)ですが、その範囲は1〜12のみです。C#チームが(8ビットの符号なし整数)intなどの小さい数値型を選択した理由は何byteですか?
9 c#  memory 

5
C / C ++で記述されたアプリケーション間でメモリを共有する方法
ロボット工学の制御のために、C / C ++で書かれたプログラムを実行しています。基本的に、3つの異なるプログラムが同時に実行され、共有メモリを介して通信します。私が見つけた周りのグーグルリンギングは、vxWorksやboostライブラリのプロセス間ヘッダーのようなものだ(Boostのドキュメント:プロセス間でのメモリの共有)。 今、私は実装を見たくありません、上のリンクを読むことができます。しかし、boostライブラリがこれをどのように実行するかについて、頭を動かすことはできません。つまり、1つのアプリケーションがメモリを割り当て、他のアプリケーションがそのメモリにアクセスしますが、それらはどのように通信しますか?これを行うのは危険ではありませんか?
9 c++  c  memory  memory-usage  boost 

3
std :: allocatorsがそれほど人気が​​ないのはなぜですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 CおよびC ++アプリケーションに関する最新の傾向、および最新とは最新の年を意味するため、がstd::allocator実際よりも頻繁に使用されることを期待していました。 現代のアプリケーションは通常、マルチスレッド化されているか、それらの形式で並行性があり、特にゲームやマルチメディアアプリケーションなどの一部の分野では、大量のメモリを管理します。そのため、通常の高額な割り当て/割り当て解除のコストが上昇し、古いアプリケーションよりもパフォーマンスに影響を与えます。 しかし、std::allocators によるこの種のメモリ管理は一般的ではないため、私が知っている1つのライブラリを数えることすらできません。つまり、標準化されたメモリ管理方法に関する理論的根拠を使用しています。 std::allocator人気がないのには本当の理由がありますか?技術的な理由?

3
オブジェクトの同一性と可変性
私はJavaの値型の提案を読んでいて、この文に出くわしました。「オブジェクトIDは可変性をサポートするためだけに機能し、オブジェクトの状態は変更できますが、同じ組み込みオブジェクトのままです。」 (仮にではあるが)私が理解していることから、オブジェクトIDは、変数がメモリ内の他の場所にあるオブジェクト(JavaまたはC#のヒープでインスタンス化されたオブジェクトなど)へのポインタまたは参照として機能するという考えです。では、これはオブジェクトの可変性とどう関係しているのでしょうか?これは、たとえば、C ++でスタックにインスタンス化されたオブジェクトが不変であることを意味しますか?ここのリンクが表示されません。

2
JavaとPHPのメモリ/ CPU消費
私はPHPベースの会社で働いています。バックエンドサービスを作成するプロジェクトがあります。Javaよりも遅いですが、ここの上級メンバーはPHPを採用しています。彼らの唯一の論点は、メモリとCPU負荷の両方の観点から見ると、JavaはPHPよりも重いということです。 JVMはコンテナー環境に似ています。荷物を多く持ち込むと、それだけ多くの量を消費しますが、ここで話しているサービスは中程度の複雑さになります。だから、それはそれほど厳しいことではないでしょう(またはそれはでしょうか?) 私はこの質問が曖昧に大きく傾いていることを理解していますが、私が考えていることは、それは常に同じケースですか?そのJavaはよりハードウェアを要求しますか?私は、実際のシナリオがどのように見えるかについて、あなたが経験したすべての人々の意見を知りたいです。
8 java  php  memory 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.