java虛擬機(jī)可能是下面三個中的一個
1:抽象規(guī)范
2:一個具體實現(xiàn)
3:一個虛擬機(jī)實例

java虛擬機(jī)的生命周期
java虛擬機(jī)的天職就是:運(yùn)行一個java程序.當(dāng)一個java程序運(yùn)行開始運(yùn)行時,一個虛擬機(jī)實例就產(chǎn)生了.當(dāng)一個計算機(jī)上同時運(yùn)行三個java程序.則將產(chǎn)生三個java虛擬機(jī)實例.每個程序運(yùn)行在自己的虛擬機(jī)里面,不會干擾.當(dāng)程序運(yùn)行完畢時,虛擬機(jī)將自動退出.

java虛擬機(jī)里面有兩種線程,守護(hù)線程和非守護(hù)線程.守護(hù)線程是說java虛擬機(jī)自己的線程,如垃圾收集線程.而非守護(hù)線程則是java中運(yùn)行的程序線程.當(dāng)非守護(hù)線程都運(yùn)行完了.java虛擬機(jī)將退出.

一個java虛擬機(jī)主要包括了:類轉(zhuǎn)載子系統(tǒng),運(yùn)行時數(shù)據(jù)區(qū),執(zhí)行引擎,內(nèi)存區(qū)等等.

運(yùn)行時數(shù)據(jù)區(qū)------主要是:1 堆 2? 方法區(qū) 3 java棧

堆和方法區(qū)對虛擬機(jī)實例中所有的對象都是共享的.而java棧區(qū),是對每個線程都是獨(dú)立的. 當(dāng)一個class被載入到 classloader中時,會解析它的類型信息.把這些類型信息放到方法區(qū),而把程序中運(yùn)行的對象,放到堆區(qū).當(dāng)一個新線程被創(chuàng)建,就分配一個新的java棧.java棧中保存的,是方法中的一些變量,狀態(tài).java棧是由很多的java棧幀組成的.一個棧幀包含了一個方法運(yùn)行的狀態(tài).當(dāng)一個方法被執(zhí)行的時候,就壓入一個新的java棧幀到j(luò)ava棧中,方法返回的時候,就把棧幀彈出來,拋棄掉.


方法區(qū)

在java虛擬機(jī)中,被裝載的類的類型信息和類的靜態(tài)變量被存儲在方法區(qū)這樣的內(nèi)存里面.java程序運(yùn)行時,會查找這些個信息.方法區(qū)的大小,是動態(tài)的.也可以不是連續(xù)的.可自由在堆中分配.也可以由用戶或者程序員指定.方法區(qū)可被垃圾收集.

方法區(qū)可以保存以下信息
這個類型的全限定名
直接超類的全限定名
是類類型還是接口
類型的訪問修飾符
任何直接超類接口的全限定名的有序列表.
該類型的常量池
字段信息 類中聲明的每個字段及其順序 如字段名,類型.修飾符號.
方法信息:如方法名,返回類型.參數(shù)表列.修飾符號.字節(jié)碼.操作數(shù)棧和棧幀中局部變量區(qū)大小等等
類靜態(tài)變量
一個到類classloader的引用
一個到class類的引用


堆
用來存儲運(yùn)行時的對象實例

java棧
每啟動一個新的線程.就會分配到一個java棧.java棧以幀為單位保存線程的運(yùn)行狀態(tài).它有兩種操作.入棧,出棧.
當(dāng)一個方法被調(diào)用時,入棧,當(dāng)一個方法返回時,出棧,或者當(dāng)方法出現(xiàn)異常.也出棧.

棧幀
組成部分 局部變量區(qū),操作數(shù)棧,幀數(shù)據(jù)區(qū).
Eliminate obsolete object references消除過期的對象引用
When you switch from a language with manual memory management, such as C or C++, to agarbage-collected language, your job as a programmer is made much easier by the fact that your objects are automatically reclaimed when you're through with them. It seems almost like magic when you first experience it. It can easily lead to the impression that you don't have to think about memory management, but this isn't quite true.
java中也要注意內(nèi)存管理

// Can you spot the "memory leak"?
public class Stack {
private Object[] elements;
private int size = 0;
public Stack(int initialCapacity) {
this.elements = new Object[initialCapacity];
}
Effective Java: Programming Language Guide
17
public void push(Object e) {
ensureCapacity();
elements[size++] = e;
}
public Object pop() {
if (size == 0)
throw new EmptyStackException();
return elements[--size];
}
/**
* Ensure space for at least one more element, roughly
* doubling the capacity each time the array needs to grow.
*/
private void ensureCapacity() {
if (elements.length == size) {
Object[] oldElements = elements;
elements = new Object[2 * elements.length + 1];
System.arraycopy(oldElements, 0, elements, 0, size);
}
}
}

這里有一個內(nèi)存泄漏
如果一個棧先是增長，然后再收縮，那么，從棧中彈出來的對象將不會被當(dāng)做垃圾回收，即使使用棧的客戶程序不再引用這些對象，它們也不會被回收。這是因為，棧內(nèi)部維護(hù)著對這些對象的過期引用（obsolete re f e re n c e）。所謂過期引用，是指永遠(yuǎn)也不會再被解除的引用

改正
public Object pop() {
if (size==0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null; // Eliminate obsolete reference清除引用
return result;
}

當(dāng)程序員第一次被類似這樣的問題困擾的時候，他們往往會過分小心：對于每一個對象引用，一旦程序不再用到它，就把它清空。這樣做既沒必要，也不是我們所期望的，因為這樣做會把程序代碼弄得很亂，并且可以想像還會降低程序的性能。“清空對象引用”這樣的操作應(yīng)該是一種例外，而不是一種規(guī)范行為。消除過期引用最好的方法是重用一個本來已經(jīng)包含對象引用的變量，或者讓這個變量結(jié)束其生命周期。如果你是在最緊湊的作用域范圍內(nèi)定義每一個變量（見第2 9條），則這種情形就會自然而然地發(fā)生。應(yīng)該注意到，在目前的J V M實現(xiàn)平臺上，僅僅退出定義變量的代碼塊是不夠的，要想使引用消失，必須退出包含該變量的方法。

一般而言，只要一個類自己管理它的內(nèi)存，程序員就應(yīng)該警惕內(nèi)存泄漏問題。一旦一個元素被釋放掉，則該元素中包含的任何對象引用應(yīng)該要被清空。

內(nèi)存泄漏的另一個常見來源是緩存。一旦你把一個對象引用放到一個緩存中，它就很容易被遺忘掉，從而使得它不再有用之后很長一段時間內(nèi)仍然留在緩存中
Avoid creating duplicate objects避免創(chuàng)建重復(fù)的對象
It is often appropriate to reuse a single object instead of creating a new functionally equivalent object each time it is needed. Reuse can be both faster and more stylish. An object can always be reused if it is immutable

String s = new String("silly"); // DON'T DO THIS!

String s = "No longer silly";//do this

In addition to reusing immutable objects, you can also reuse mutable objects that you know will not be modified. Here is a slightly more subtle and much more common example of what not to do, involving mutable objects that are never modified once their values have been computed:
除了重用非可變的對象之外，對于那些已知不會被修改的可變對象，你也可以重用它們。

such as
public class Person {
private final Date birthDate;
// Other fields omitted
public Person(Date birthDate) {
this.birthDate = birthDate;
}
// DON'T DO THIS!
public boolean isBabyBoomer() {
Calendar gmtCal =
Calendar.getInstance(TimeZone.getTimeZone("GMT"));
gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
Date boomStart = gmtCal.getTime();
gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
Date boomEnd = gmtCal.getTime();
return birthDate.compareTo(boomStart) >= 0 &&
birthDate.compareTo(boomEnd) < 0;
}
}

改良的版本.
The isBabyBoomer method unnecessarily creates a new Calendar, TimeZone, and two Date instances each time it is invoked. The version that follows avoids this inefficiency with a static initializer:

class Person {
private final Date birthDate;
public Person(Date birthDate) {
this.birthDate = birthDate;
}
/**
* The starting and ending dates of the baby boom.
*/
private static final Date BOOM_START;
private static final Date BOOM_END;
static {
Calendar gmtCal =
Calendar.getInstance(TimeZone.getTimeZone("GMT"));
gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
BOOM_START = gmtCal.getTime();
gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
BOOM_END = gmtCal.getTime();
}
public boolean isBabyBoomer() {
return birthDate.compareTo(BOOM_START) >= 0 &&
birthDate.compareTo(BOOM_END) < 0;
}
}

。一個適配器是指這樣一個對象：它把功能委
托給后面的一個對象，從而為后面的對象提供一個可選的接口。由于適配器除了后面的對象之外，沒有其他的狀態(tài)信息，所以針對某個給定對象的特定適配器而言，它不需要創(chuàng)建多個適配器實例。

This item should not be misconstrued to imply that object creation is expensive and should be avoided. On the contrary, the creation and reclamation of small objects whose constructors do little explicit work is cheap, especially on modern JVM implementations. Creating additional objects to enhance the clarity, simplicity, or power of a program is generally a good thing.
Conversely, avoiding object creation by maintaining your own object pool is a bad idea unless the objects in the pool are extremely heavyweight. A prototypical example of an object that does justify an object pool is a database connection. The cost of establishing the connection is sufficiently high that it makes sense to reuse these objects. Generally speaking, however, maintaining your own object pools clutters up your code, increases memory footprint, and harms performance. Modern JVM implementations have highly optimized garbage collectors that easily outperform such object pools on lightweight objects.