、適切な場面で単一ケースを使うようにします。
シングルケースの使用は、積載の負担を軽減し、積載時間を短縮し、積載効率を向上させることができますが、すべての場所がシングルケースに適しているわけではありません：
まず、リソースの使用制御と、スレッド同期によるリソースへの同時アクセスの制御です；
第二に、リソースを節約するためにインスタンスの生成が制御されています；
第三に、データ共有を制御することで、直接的な関連を確立することなく、無関係な複数のプロセスやスレッド間の通信を可能にします。
, 静的変数の恣意的な使用を避けるようにします。
オブジェクトが静的変数への参照として定義されている場合、GCは通常
この時点で、静的変数bのライフサイクルはクラスAと同期しています。クラスAがアンロードされない場合、bオブジェクトはプログラムが終了するまでメモリに常駐します。
、あまりにも頻繁にJavaオブジェクトを作成しないようにしてください。
頻繁に呼び出されるメソッドやループの中では、新しいオブジェクトを作らないようにしましょう。システムがオブジェクトを生成するのに時間を費やすだけでなく、これらのオブジェクトの収集や廃棄に時間を費やすことになります。
最後の修飾語を使ってみてください
final修飾子を持つクラスは派生不可能です。java、lang、Stringなど、JAVAのコアAPIにはfinalの応用例がたくさんあります。 Stringクラスにfinalを指定することで、length()メソッドのオーバーライドを防ぐことができます。また、クラスがfinalの場合、そのクラスのすべてのメソッドがfinalになります。javaコンパイラは、すべてのfinalメソッドをインライン化する機会を探します。
例えば、インスタンス内の変数にアクセスするゲッター/セッターメソッドを「final」にします：
単純なgetter/setterメソッドはfinalにすべきです。これはコンパイラにそのメソッドがオーバーロードされないことを伝え、例えば「インライン化」することができます：
できるだけローカル変数を使う
メソッド呼び出し中に渡される引数や呼び出し中に作成される一時変数はスタック上に保持され、高速に処理されます。スタティック変数やインスタンス変数など、その他の変数はヒープに作成され、低速に処理されます。
つの使用場所の包装形態と基本形態への対応を図ります。
パッケージング型とプロセスの使用の基本的な型は、お互いに変換することができますが、それらは両方のメモリ領域によって生成される完全に異なっている、データの基本的な型を生成し、スタック処理で処理、パッケージング型は、オブジェクトは、ヒープ内のインスタンスを生成することです。オブジェクトのコレクションでは、パッケージ型のアプリケーションの面で処理する必要があるオブジェクトがあり、他の処理は、基本的な型の使用を提唱。
、同期の慎重な使用は、同期のメソッドを減らすようにしてください。
私たちはすべて知っているように、同期の実装では、価格として大きなシステムオーバーヘッドであることであり、さらにデッドロックを引き起こす可能性がありますので、不要な同期制御を避けるようにしてください。synchronizeメソッドが呼び出され、直接現在のオブジェクトのロックになり、他のスレッドの実行後のメソッドでは、現在のオブジェクトの他のメソッドを呼び出すことはできません。したがって、synchronizeメソッドは、可能な限り小さくする必要があり、コードブロックの同期ではなく、メソッドの同期を使用してみてください。
, finalizeメソッドを使わないようにします。
実際には、リソースのクリーンアップを完了するためにfinalizeメソッドに置くことは非常に悪い選択ですが、GCの作業負荷のために、特に若い世代のメモリを取り戻すとき、それらのほとんどは、アプリケーションが一時停止する原因となりますので、リソースのクリーンアップのためにfinalizeメソッドを使用することを選択すると、GCに大きな負担につながる、プログラムがより非効率的に実行されます。
上記の方法では、「hello」文字列が作成され、JVMの文字キャッシュ・プールがこの文字列をキャッシュします；
この時点で、Stringオブジェクトが参照するstrは、文字列の生成に加えて、char []配列も下部に含んでいます。このchar []配列は、h,e,l,l,oの順に格納されています。
