int i=100; String binStr=Integer.toBinaryString(i); String otcStr=Integer.toOctalString(i); String hexStr=Integer.toHexString(i); System.out.println(binStr); System.out.println(otcStr); System.out.println(hexStr);

2，java 如何實(shí)現(xiàn)程序的自動(dòng)更新，有例子最好了

做一個(gè)線程 過一段時(shí)間 就連接指定的遠(yuǎn)程服務(wù)器 看最新版本號(hào) 與本地當(dāng)前版本號(hào)是不是一致 是的話 就彈出窗口 提示用戶 用戶確認(rèn)就 自動(dòng)下載下來 然后更新原來的class 再啟動(dòng) 過程就是這樣 自己寫一個(gè)小小的代碼測(cè)試一下就可以

2004 年 11 月 29 日

本文將對(duì) Linux™ 程序員可以使用的內(nèi)存管理技術(shù)進(jìn)行概述，雖然關(guān)注的重點(diǎn)是 C 語言，但同樣也適用于其他語言。文中將為您提供如何管理內(nèi)存的細(xì)節(jié)，然后將進(jìn)一步展示如何手工管理內(nèi)存，如何使用引用計(jì)數(shù)或者內(nèi)存池來半手工地管理內(nèi)存，以及如何使用垃圾收集自動(dòng)管理內(nèi)存。

為什么必須管理內(nèi)存

內(nèi)存管理是計(jì)算機(jī)編程最為基本的領(lǐng)域之一。在很多腳本語言中，您不必?fù)?dān)心內(nèi)存是如何管理的，這并不能使得內(nèi)存管理的重要性有一點(diǎn)點(diǎn)降低。對(duì)實(shí)際編程來說，理解您的內(nèi)存管理器的能力與局限性至關(guān)重要。在大部分系統(tǒng)語言中，比如 C 和 C++，您必須進(jìn)行內(nèi)存管理。本文將介紹手工的、半手工的以及自動(dòng)的內(nèi)存管理實(shí)踐的基本概念。

追溯到在 Apple II 上進(jìn)行匯編語言編程的時(shí)代，那時(shí)內(nèi)存管理還不是個(gè)大問題。您實(shí)際上在運(yùn)行整個(gè)系統(tǒng)。系統(tǒng)有多少內(nèi)存，您就有多少內(nèi)存。您甚至不必費(fèi)心思去弄明白它有多少內(nèi)存，因?yàn)槊恳慌_(tái)機(jī)器的內(nèi)存數(shù)量都相同。所以，如果內(nèi)存需要非常固定，那么您只需要選擇一個(gè)內(nèi)存范圍并使用它即可。

不過，即使是在這樣一個(gè)簡(jiǎn)單的計(jì)算機(jī)中，您也會(huì)有問題，尤其是當(dāng)您不知道程序的每個(gè)部分將需要多少內(nèi)存時(shí)。如果您的空間有限，而內(nèi)存需求是變化的，那么您需要一些方法來滿足這些需求：

• 確定您是否有足夠的內(nèi)存來處理數(shù)據(jù)。
• 從可用的內(nèi)存中獲取一部分內(nèi)存。
• 向可用內(nèi)存池（pool）中返回部分內(nèi)存，以使其可以由程序的其他部分或者其他程序使用。

實(shí)現(xiàn)這些需求的程序庫稱為 分配程序（allocators），因?yàn)樗鼈冐?fù)責(zé)分配和回收內(nèi)存。程序的動(dòng)態(tài)性越強(qiáng)，內(nèi)存管理就越重要，您的內(nèi)存分配程序的選擇也就更重要。讓我們來了解可用于內(nèi)存管理的不同方法，它們的好處與不足，以及它們最適用的情形。

回頁首

C 風(fēng)格的內(nèi)存分配程序

C 編程語言提供了兩個(gè)函數(shù)來滿足我們的三個(gè)需求：

• malloc：該函數(shù)分配給定的字節(jié)數(shù)，并返回一個(gè)指向它們的指針。如果沒有足夠的可用內(nèi)存，那么它返回一個(gè)空指針。
• free：該函數(shù)獲得指向由 malloc 分配的內(nèi)存片段的指針，并將其釋放，以便以后的程序或操作系統(tǒng)使用（實(shí)際上，一些 malloc 實(shí)現(xiàn)只能將內(nèi)存歸還給程序，而無法將內(nèi)存歸還給操作系統(tǒng)）。

物理內(nèi)存和虛擬內(nèi)存

要理解內(nèi)存在程序中是如何分配的，首先需要理解如何將內(nèi)存從操作系統(tǒng)分配給程序。計(jì)算機(jī)上的每一個(gè)進(jìn)程都認(rèn)為自己可以訪問所有的物理內(nèi)存。顯然，由于同時(shí)在運(yùn)行多個(gè)程序，所以每個(gè)進(jìn)程不可能擁有全部?jī)?nèi)存。實(shí)際上，這些進(jìn)程使用的是 虛擬內(nèi)存。

只是作為一個(gè)例子，讓我們假定您的程序正在訪問地址為 629 的內(nèi)存。不過，虛擬內(nèi)存系統(tǒng)不需要將其存儲(chǔ)在位置為 629 的 RAM 中。實(shí)際上，它甚至可以不在 RAM 中 —— 如果物理 RAM 已經(jīng)滿了，它甚至可能已經(jīng)被轉(zhuǎn)移到硬盤上！由于這類地址不必反映內(nèi)存所在的物理位置，所以它們被稱為虛擬內(nèi)存。操作系統(tǒng)維持著一個(gè)虛擬地址到物理地址的轉(zhuǎn)換的表，以便計(jì)算機(jī)硬件可以正確地響應(yīng)地址請(qǐng)求。并且，如果地址在硬盤上而不是在 RAM 中，那么操作系統(tǒng)將暫時(shí)停止您的進(jìn)程，將其他內(nèi)存轉(zhuǎn)存到硬盤中，從硬盤上加載被請(qǐng)求的內(nèi)存，然后再重新啟動(dòng)您的進(jìn)程。這樣，每個(gè)進(jìn)程都獲得了自己可以使用的地址空間，可以訪問比您物理上安裝的內(nèi)存更多的內(nèi)存。

在 32-位 x86 系統(tǒng)上，每一個(gè)進(jìn)程可以訪問 4 GB 內(nèi)存。現(xiàn)在，大部分人的系統(tǒng)上并沒有 4 GB 內(nèi)存，即使您將 swap 也算上， 每個(gè)進(jìn)程所使用的內(nèi)存也肯定少于 4 GB。因此，當(dāng)加載一個(gè)進(jìn)程時(shí)，它會(huì)得到一個(gè)取決于某個(gè)稱為 系統(tǒng)中斷點(diǎn)（system break）的特定地址的初始內(nèi)存分配。該地址之后是未被映射的內(nèi)存 —— 用于在 RAM 或者硬盤中沒有分配相應(yīng)物理位置的內(nèi)存。因此，如果一個(gè)進(jìn)程運(yùn)行超出了它初始分配的內(nèi)存，那么它必須請(qǐng)求操作系統(tǒng)“映射進(jìn)來（map in）”更多的內(nèi)存。（映射是一個(gè)表示一一對(duì)應(yīng)關(guān)系的數(shù)學(xué)術(shù)語 —— 當(dāng)內(nèi)存的虛擬地址有一個(gè)對(duì)應(yīng)的物理地址來存儲(chǔ)內(nèi)存內(nèi)容時(shí)，該內(nèi)存將被映射。）

基于 UNIX 的系統(tǒng)有兩個(gè)可映射到附加內(nèi)存中的基本系統(tǒng)調(diào)用：

• brk： brk() 是一個(gè)非常簡(jiǎn)單的系統(tǒng)調(diào)用。還記得系統(tǒng)中斷點(diǎn)嗎？該位置是進(jìn)程映射的內(nèi)存邊界。 brk() 只是簡(jiǎn)單地將這個(gè)位置向前或者向后移動(dòng)，就可以向進(jìn)程添加內(nèi)存或者從進(jìn)程取走內(nèi)存。
• mmap： mmap()，或者說是“內(nèi)存映像”，類似于 brk()，但是更為靈活。首先，它可以映射任何位置的內(nèi)存，而不單單只局限于進(jìn)程。其次，它不僅可以將虛擬地址映射到物理的 RAM 或者 swap，它還可以將它們映射到文件和文件位置，這樣，讀寫內(nèi)存將對(duì)文件中的數(shù)據(jù)進(jìn)行讀寫。不過，在這里，我們只關(guān)心 mmap 向進(jìn)程添加被映射的內(nèi)存的能力。 munmap() 所做的事情與 mmap() 相反。

如您所見， brk() 或者 mmap() 都可以用來向我們的進(jìn)程添加額外的虛擬內(nèi)存。在我們的例子中將使用 brk()，因?yàn)樗?jiǎn)單，更通用。

實(shí)現(xiàn)一個(gè)簡(jiǎn)單的分配程序

如果您曾經(jīng)編寫過很多 C 程序，那么您可能曾多次使用過 malloc() 和 free()。不過，您可能沒有用一些時(shí)間去思考它們?cè)谀牟僮飨到y(tǒng)中是如何實(shí)現(xiàn)的。本節(jié)將向您展示 malloc 和 free 的一個(gè)最簡(jiǎn)化實(shí)現(xiàn)的代碼，來幫助說明管理內(nèi)存時(shí)都涉及到了哪些事情。

要試著運(yùn)行這些示例，需要先 復(fù)制本代碼清單，并將其粘貼到一個(gè)名為 malloc.c 的文件中。接下來，我將一次一個(gè)部分地對(duì)該清單進(jìn)行解釋。

在大部分操作系統(tǒng)中，內(nèi)存分配由以下兩個(gè)簡(jiǎn)單的函數(shù)來處理：

• void *malloc(long numbytes)：該函數(shù)負(fù)責(zé)分配 numbytes 大小的內(nèi)存，并返回指向第一個(gè)字節(jié)的指針。
• void free(void *firstbyte)：如果給定一個(gè)由先前的 malloc 返回的指針，那么該函數(shù)會(huì)將分配的空間歸還給進(jìn)程的“空閑空間”。

malloc_init 將是初始化內(nèi)存分配程序的函數(shù)。它要完成以下三件事：將分配程序標(biāo)識(shí)為已經(jīng)初始化，找到系統(tǒng)中最后一個(gè)有效內(nèi)存地址，然后建立起指向我們管理的內(nèi)存的指針。這三個(gè)變量都是全局變量：

            int has_initialized = 0;
            void *managed_memory_start;
            void *last_valid_address;
            

如前所述，被映射的內(nèi)存的邊界（最后一個(gè)有效地址）常被稱為系統(tǒng)中斷點(diǎn)或者 當(dāng)前中斷點(diǎn)。在很多 UNIX® 系統(tǒng)中，為了指出當(dāng)前系統(tǒng)中斷點(diǎn)，必須使用 sbrk(0) 函數(shù)。 sbrk 根據(jù)參數(shù)中給出的字節(jié)數(shù)移動(dòng)當(dāng)前系統(tǒng)中斷點(diǎn)，然后返回新的系統(tǒng)中斷點(diǎn)。使用參數(shù) 0 只是返回當(dāng)前中斷點(diǎn)。這里是我們的 malloc 初始化代碼，它將找到當(dāng)前中斷點(diǎn)并初始化我們的變量：

            /* Include the sbrk function */
            #include <unistd.h>
            void malloc_init()
            {
            /* grab the last valid address from the OS */
            last_valid_address = sbrk(0);
            /* we don't have any memory to manage yet, so
            *just set the beginning to be last_valid_address
            */
            managed_memory_start = last_valid_address;
            /* Okay, we're initialized and ready to go */
            has_initialized = 1;
            }
            

現(xiàn)在，為了完全地管理內(nèi)存，我們需要能夠追蹤要分配和回收哪些內(nèi)存。在對(duì)內(nèi)存塊進(jìn)行了 free 調(diào)用之后，我們需要做的是諸如將它們標(biāo)記為未被使用的等事情，并且，在調(diào)用 malloc 時(shí)，我們要能夠定位未被使用的內(nèi)存塊。因此， malloc 返回的每塊內(nèi)存的起始處首先要有這個(gè)結(jié)構(gòu)：

            struct mem_control_block {
            int is_available;
            int size;
            };
            

現(xiàn)在，您可能會(huì)認(rèn)為當(dāng)程序調(diào)用 malloc 時(shí)這會(huì)引發(fā)問題 —— 它們?nèi)绾沃肋@個(gè)結(jié)構(gòu)？答案是它們不必知道；在返回指針之前，我們會(huì)將其移動(dòng)到這個(gè)結(jié)構(gòu)之后，把它隱藏起來。這使得返回的指針指向沒有用于任何其他用途的內(nèi)存。那樣，從調(diào)用程序的角度來看，它們所得到的全部是空閑的、開放的內(nèi)存。然后，當(dāng)通過 free() 將該指針傳遞回來時(shí)，我們只需要倒退幾個(gè)內(nèi)存字節(jié)就可以再次找到這個(gè)結(jié)構(gòu)。

在討論分配內(nèi)存之前，我們將先討論釋放，因?yàn)樗?jiǎn)單。為了釋放內(nèi)存，我們必須要做的惟一一件事情就是，獲得我們給出的指針，回退 sizeof(struct mem_control_block) 個(gè)字節(jié)，并將其標(biāo)記為可用的。這里是對(duì)應(yīng)的代碼：

            void free(void *firstbyte) {
            struct mem_control_block *mcb;
            /* Backup from the given pointer to find the
            * mem_control_block
            */
            mcb = firstbyte - sizeof(struct mem_control_block);
            /* Mark the block as being available */
            mcb->is_available = 1;
            /* That's It!  We're done. */
            return;
            }
            

如您所見，在這個(gè)分配程序中，內(nèi)存的釋放使用了一個(gè)非常簡(jiǎn)單的機(jī)制，在固定時(shí)間內(nèi)完成內(nèi)存釋放。分配內(nèi)存稍微困難一些。以下是該算法的略述：

            1. If our allocator has not been initialized, initialize it.
            2. Add sizeof(struct mem_control_block) to the size requested.
            3. start at managed_memory_start.
            4. Are we at last_valid address?
            5. If we are:
            A. We didn't find any existing space that was large enough
            -- ask the operating system for more and return that.
            6. Otherwise:
            A. Is the current space available (check is_available from
            the mem_control_block)?
            B. If it is:
            i)   Is it large enough (check "size" from the
            mem_control_block)?
            ii)  If so:
            a. Mark it as unavailable
            b. Move past mem_control_block and return the
            pointer
            iii) Otherwise:
            a. Move forward "size" bytes
            b. Go back go step 4
            C. Otherwise:
            i)   Move forward "size" bytes
            ii)  Go back to step 4
            

我們主要使用連接的指針遍歷內(nèi)存來尋找開放的內(nèi)存塊。這里是代碼：

            void *malloc(long numbytes) {
            /* Holds where we are looking in memory */
            void *current_location;
            /* This is the same as current_location, but cast to a
            * memory_control_block
            */
            struct mem_control_block *current_location_mcb;
            /* This is the memory location we will return.  It will
            * be set to 0 until we find something suitable
            */
            void *memory_location;
            /* Initialize if we haven't already done so */
            if(! has_initialized) 	{
            malloc_init();
            }
            /* The memory we search for has to include the memory
            * control block, but the users of malloc don't need
            * to know this, so we'll just add it in for them.
            */
            numbytes = numbytes + sizeof(struct mem_control_block);
            /* Set memory_location to 0 until we find a suitable
            * location
            */
            memory_location = 0;
            /* Begin searching at the start of managed memory */
            current_location = managed_memory_start;
            /* Keep going until we have searched all allocated space */
            while(current_location != last_valid_address)
            {
            /* current_location and current_location_mcb point
            * to the same address.  However, current_location_mcb
            * is of the correct type, so we can use it as a struct.
            * current_location is a void pointer so we can use it
            * to calculate addresses.
            */
            current_location_mcb =
            (struct mem_control_block *)current_location;
            if(current_location_mcb->is_available)
            {
            if(current_location_mcb->size >= numbytes)
            {
            /* Woohoo!  We've found an open,
            * appropriately-size location.
            */
            /* It is no longer available */
            current_location_mcb->is_available = 0;
            /* We own it */
            memory_location = current_location;
            /* Leave the loop */
            break;
            }
            }
            /* If we made it here, it's because the Current memory
            * block not suitable; move to the next one
            */
            current_location = current_location +
            current_location_mcb->size;
            }
            /* If we still don't have a valid location, we'll
            * have to ask the operating system for more memory
            */
            if(! memory_location)
            {
            /* Move the program break numbytes further */
            sbrk(numbytes);
            /* The new memory will be where the last valid
            * address left off
            */
            memory_location = last_valid_address;
            /* We'll move the last valid address forward
            * numbytes
            */
            last_valid_address = last_valid_address + numbytes;
            /* We need to initialize the mem_control_block */
            current_location_mcb = memory_location;
            current_location_mcb->is_available = 0;
            current_location_mcb->size = numbytes;
            }
            /* Now, no matter what (well, except for error conditions),
            * memory_location has the address of the memory, including
            * the mem_control_block
            */
            /* Move the pointer past the mem_control_block */
            memory_location = memory_location + sizeof(struct mem_control_block);
            /* Return the pointer */
            return memory_location;
            }
            

這就是我們的內(nèi)存管理器。現(xiàn)在，我們只需要構(gòu)建它，并在程序中使用它即可。

運(yùn)行下面的命令來構(gòu)建 malloc 兼容的分配程序（實(shí)際上，我們忽略了 realloc() 等一些函數(shù)，不過， malloc() 和 free() 才是最主要的函數(shù)）：

            gcc -shared -fpic malloc.c -o malloc.so
            

該程序?qū)⑸梢粋€(gè)名為 malloc.so 的文件，它是一個(gè)包含有我們的代碼的共享庫。

在 UNIX 系統(tǒng)中，現(xiàn)在您可以用您的分配程序來取代系統(tǒng)的 malloc()，做法如下：

            LD_PRELOAD=/path/to/malloc.so
            export LD_PRELOAD
            

LD_PRELOAD 環(huán)境變量使動(dòng)態(tài)鏈接器在加載任何可執(zhí)行程序之前，先加載給定的共享庫的符號(hào)。它還為特定庫中的符號(hào)賦予優(yōu)先權(quán)。因此，從現(xiàn)在起，該會(huì)話中的任何應(yīng)用程序都將使用我們的 malloc()，而不是只有系統(tǒng)的應(yīng)用程序能夠使用。有一些應(yīng)用程序不使用 malloc()，不過它們是例外。其他使用 realloc() 等其他內(nèi)存管理函數(shù)的應(yīng)用程序，或者錯(cuò)誤地假定 malloc() 內(nèi)部行為的那些應(yīng)用程序，很可能會(huì)崩潰。ash shell 似乎可以使用我們的新 malloc() 很好地工作。

如果您想確保 malloc() 正在被使用，那么您應(yīng)該通過向函數(shù)的入口點(diǎn)添加 write() 調(diào)用來進(jìn)行測(cè)試。

我們的內(nèi)存管理器在很多方面都還存在欠缺，但它可以有效地展示內(nèi)存管理需要做什么事情。它的某些缺點(diǎn)包括：

• 由于它對(duì)系統(tǒng)中斷點(diǎn)（一個(gè)全局變量）進(jìn)行操作，所以它不能與其他分配程序或者 mmap 一起使用。
• 當(dāng)分配內(nèi)存時(shí)，在最壞的情形下，它將不得不遍歷 全部進(jìn)程內(nèi)存；其中可能包括位于硬盤上的很多內(nèi)存，這意味著操作系統(tǒng)將不得不花時(shí)間去向硬盤移入數(shù)據(jù)和從硬盤中移出數(shù)據(jù)。
• 沒有很好的內(nèi)存不足處理方案（ malloc 只假定內(nèi)存分配是成功的）。
• 它沒有實(shí)現(xiàn)很多其他的內(nèi)存函數(shù)，比如 realloc()。
• 由于 sbrk() 可能會(huì)交回比我們請(qǐng)求的更多的內(nèi)存，所以在堆（heap）的末端會(huì)遺漏一些內(nèi)存。
• 雖然 is_available 標(biāo)記只包含一位信息，但它要使用完整的 4-字節(jié) 的字。
• 分配程序不是線程安全的。
• 分配程序不能將空閑空間拼合為更大的內(nèi)存塊。
• 分配程序的過于簡(jiǎn)單的匹配算法會(huì)導(dǎo)致產(chǎn)生很多潛在的內(nèi)存碎片。
• 我確信還有很多其他問題。這就是為什么它只是一個(gè)例子!

其他 malloc 實(shí)現(xiàn)

malloc() 的實(shí)現(xiàn)有很多，這些實(shí)現(xiàn)各有優(yōu)點(diǎn)與缺點(diǎn)。在設(shè)計(jì)一個(gè)分配程序時(shí)，要面臨許多需要折衷的選擇，其中包括：

• 分配的速度。
• 回收的速度。
• 有線程的環(huán)境的行為。
• 內(nèi)存將要被用光時(shí)的行為。
• 局部緩存。
• 簿記（Bookkeeping）內(nèi)存開銷。
• 虛擬內(nèi)存環(huán)境中的行為。
• 小的或者大的對(duì)象。
• 實(shí)時(shí)保證。

每一個(gè)實(shí)現(xiàn)都有其自身的優(yōu)缺點(diǎn)集合。在我們的簡(jiǎn)單的分配程序中，分配非常慢，而回收非常快。另外，由于它在使用虛擬內(nèi)存系統(tǒng)方面較差，所以它最適于處理大的對(duì)象。

還有其他許多分配程序可以使用。其中包括：

• Doug Lea Malloc：Doug Lea Malloc 實(shí)際上是完整的一組分配程序，其中包括 Doug Lea 的原始分配程序，GNU libc 分配程序和 ptmalloc。 Doug Lea 的分配程序有著與我們的版本非常類似的基本結(jié)構(gòu)，但是它加入了索引，這使得搜索速度更快，并且可以將多個(gè)沒有被使用的塊組合為一個(gè)大的塊。它還支持緩存，以便更快地再次使用最近釋放的內(nèi)存。 ptmalloc 是 Doug Lea Malloc 的一個(gè)擴(kuò)展版本，支持多線程。在本文后面的 參考資料部分中，有一篇描述 Doug Lea 的 Malloc 實(shí)現(xiàn)的文章。
• BSD Malloc：BSD Malloc 是隨 4.2 BSD 發(fā)行的實(shí)現(xiàn)，包含在 FreeBSD 之中，這個(gè)分配程序可以從預(yù)先確實(shí)大小的對(duì)象構(gòu)成的池中分配對(duì)象。它有一些用于對(duì)象大小的 size 類，這些對(duì)象的大小為 2 的若干次冪減去某一常數(shù)。所以，如果您請(qǐng)求給定大小的一個(gè)對(duì)象，它就簡(jiǎn)單地分配一個(gè)與之匹配的 size 類。這樣就提供了一個(gè)快速的實(shí)現(xiàn)，但是可能會(huì)浪費(fèi)內(nèi)存。在 參考資料部分中，有一篇描述該實(shí)現(xiàn)的文章。
• Hoard：編寫 Hoard 的目標(biāo)是使內(nèi)存分配在多線程環(huán)境中進(jìn)行得非常快。因此，它的構(gòu)造以鎖的使用為中心，從而使所有進(jìn)程不必等待分配內(nèi)存。它可以顯著地加快那些進(jìn)行很多分配和回收的多線程進(jìn)程的速度。在 參考資料部分中，有一篇描述該實(shí)現(xiàn)的文章。

眾多可用的分配程序中最有名的就是上述這些分配程序。如果您的程序有特別的分配需求，那么您可能更愿意編寫一個(gè)定制的能匹配您的程序內(nèi)存分配方式的分配程序。不過，如果不熟悉分配程序的設(shè)計(jì)，那么定制分配程序通常會(huì)帶來比它們解決的問題更多的問題。要獲得關(guān)于該主題的適當(dāng)?shù)慕榻B，請(qǐng)參閱 Donald Knuth 撰寫的 The Art of Computer Programming Volume 1: Fundamental Algorithms 中的第 2.5 節(jié)“Dynamic Storage Allocation”（請(qǐng)參閱 參考資料中的鏈接）。它有點(diǎn)過時(shí)，因?yàn)樗鼪]有考慮虛擬內(nèi)存環(huán)境，不過大部分算法都是基于前面給出的函數(shù)。

在 C++ 中，通過重載 operator new()，您可以以每個(gè)類或者每個(gè)模板為單位實(shí)現(xiàn)自己的分配程序。在 Andrei Alexandrescu 撰寫的 Modern C++ Design 的第 4 章（“Small Object Allocation”）中，描述了一個(gè)小對(duì)象分配程序（請(qǐng)參閱 參考資料中的鏈接）。

基于 malloc() 的內(nèi)存管理的缺點(diǎn)

不只是我們的內(nèi)存管理器有缺點(diǎn)，基于 malloc() 的內(nèi)存管理器仍然也有很多缺點(diǎn)，不管您使用的是哪個(gè)分配程序。對(duì)于那些需要保持長(zhǎng)期存儲(chǔ)的程序使用 malloc() 來管理內(nèi)存可能會(huì)非常令人失望。如果您有大量的不固定的內(nèi)存引用，經(jīng)常難以知道它們何時(shí)被釋放。生存期局限于當(dāng)前函數(shù)的內(nèi)存非常容易管理，但是對(duì)于生存期超出該范圍的內(nèi)存來說，管理內(nèi)存則困難得多。而且，關(guān)于內(nèi)存管理是由進(jìn)行調(diào)用的程序還是由被調(diào)用的函數(shù)來負(fù)責(zé)這一問題，很多 API 都不是很明確。

因?yàn)楣芾韮?nèi)存的問題，很多程序傾向于使用它們自己的內(nèi)存管理規(guī)則。C++ 的異常處理使得這項(xiàng)任務(wù)更成問題。有時(shí)好像致力于管理內(nèi)存分配和清理的代碼比實(shí)際完成計(jì)算任務(wù)的代碼還要多！因此，我們將研究?jī)?nèi)存管理的其他選擇。

回頁首

半自動(dòng)內(nèi)存管理策略

引用計(jì)數(shù)

引用計(jì)數(shù)是一種 半自動(dòng)（semi-automated）的內(nèi)存管理技術(shù)，這表示它需要一些編程支持，但是它不需要您確切知道某一對(duì)象何時(shí)不再被使用。引用計(jì)數(shù)機(jī)制為您完成內(nèi)存管理任務(wù)。

在引用計(jì)數(shù)中，所有共享的數(shù)據(jù)結(jié)構(gòu)都有一個(gè)域來包含當(dāng)前活動(dòng)“引用”結(jié)構(gòu)的次數(shù)。當(dāng)向一個(gè)程序傳遞一個(gè)指向某個(gè)數(shù)據(jù)結(jié)構(gòu)指針時(shí)，該程序會(huì)將引用計(jì)數(shù)增加 1。實(shí)質(zhì)上，您是在告訴數(shù)據(jù)結(jié)構(gòu)，它正在被存儲(chǔ)在多少個(gè)位置上。然后，當(dāng)您的進(jìn)程完成對(duì)它的使用后，該程序就會(huì)將引用計(jì)數(shù)減少 1。結(jié)束這個(gè)動(dòng)作之后，它還會(huì)檢查計(jì)數(shù)是否已經(jīng)減到零。如果是，那么它將釋放內(nèi)存。

這樣做的好處是，您不必追蹤程序中某個(gè)給定的數(shù)據(jù)結(jié)構(gòu)可能會(huì)遵循的每一條路徑。每次對(duì)其局部的引用，都將導(dǎo)致計(jì)數(shù)的適當(dāng)增加或減少。這樣可以防止在使用數(shù)據(jù)結(jié)構(gòu)時(shí)釋放該結(jié)構(gòu)。不過，當(dāng)您使用某個(gè)采用引用計(jì)數(shù)的數(shù)據(jù)結(jié)構(gòu)時(shí)，您必須記得運(yùn)行引用計(jì)數(shù)函數(shù)。另外，內(nèi)置函數(shù)和第三方的庫不會(huì)知道或者可以使用您的引用計(jì)數(shù)機(jī)制。引用計(jì)數(shù)也難以處理發(fā)生循環(huán)引用的數(shù)據(jù)結(jié)構(gòu)。

要實(shí)現(xiàn)引用計(jì)數(shù)，您只需要兩個(gè)函數(shù) —— 一個(gè)增加引用計(jì)數(shù)，一個(gè)減少引用計(jì)數(shù)并當(dāng)計(jì)數(shù)減少到零時(shí)釋放內(nèi)存。

一個(gè)示例引用計(jì)數(shù)函數(shù)集可能看起來如下所示：

            /* Structure Definitions*/
            /* Base structure that holds a refcount */
            struct refcountedstruct
            {
            int refcount;
            }
            /* All refcounted structures must mirror struct
            * refcountedstruct for their first variables
            */
            /* Refcount maintenance functions */
            /* Increase reference count */
            void REF(void *data)
            {
            struct refcountedstruct *rstruct;
            rstruct = (struct refcountedstruct *) data;
            rstruct->refcount++;
            }
            /* Decrease reference count */
            void UNREF(void *data)
            {
            struct refcountedstruct *rstruct;
            rstruct = (struct refcountedstruct *) data;
            rstruct->refcount--;
            /* Free the structure if there are no more users */
            if(rstruct->refcount == 0)
            {
            free(rstruct);
            }
            }
            

REF 和 UNREF 可能會(huì)更復(fù)雜，這取決于您想要做的事情。例如，您可能想要為多線程程序增加鎖，那么您可能想擴(kuò)展 refcountedstruct，使它同樣包含一個(gè)指向某個(gè)在釋放內(nèi)存之前要調(diào)用的函數(shù)的指針（類似于面向?qū)ο笳Z言中的析構(gòu)函數(shù) —— 如果您的結(jié)構(gòu)中包含這些指針，那么這是 必需的）。

當(dāng)使用 REF 和 UNREF 時(shí)，您需要遵守這些指針的分配規(guī)則：

• UNREF 分配前左端指針（left-hand-side pointer）指向的值。
• REF 分配后左端指針（left-hand-side pointer）指向的值。

在傳遞使用引用計(jì)數(shù)的結(jié)構(gòu)的函數(shù)中，函數(shù)需要遵循以下這些規(guī)則：

• 在函數(shù)的起始處 REF 每一個(gè)指針。
• 在函數(shù)的結(jié)束處 UNREF 第一個(gè)指針。

以下是一個(gè)使用引用計(jì)數(shù)的生動(dòng)的代碼示例：

            /* EXAMPLES OF USAGE */
            /* Data type to be refcounted */
            struct mydata
            {
            int refcount; /* same as refcountedstruct */
            int datafield1; /* Fields specific to this struct */
            int datafield2;
            /* other declarations would go here as appropriate */
            };
            /* Use the functions in code */
            void dosomething(struct mydata *data)
            {
            REF(data);
            /* Process data */
            /* when we are through */
            UNREF(data);
            }
            struct mydata *globalvar1;
            /* Note that in this one, we don't decrease the
            * refcount since we are maintaining the reference
            * past the end of the function call through the
            * global variable
            */
            void storesomething(struct mydata *data)
            {
            REF(data); /* passed as a parameter */
            globalvar1 = data;
            REF(data); /* ref because of Assignment */
            UNREF(data); /* Function finished */
            }
            

由于引用計(jì)數(shù)是如此簡(jiǎn)單，大部分程序員都自已去實(shí)現(xiàn)它，而不是使用庫。不過，它們依賴于 malloc 和 free 等低層的分配程序來實(shí)際地分配和釋放它們的內(nèi)存。

在 Perl 等高級(jí)語言中，進(jìn)行內(nèi)存管理時(shí)使用引用計(jì)數(shù)非常廣泛。在這些語言中，引用計(jì)數(shù)由語言自動(dòng)地處理，所以您根本不必?fù)?dān)心它，除非要編寫擴(kuò)展模塊。由于所有內(nèi)容都必須進(jìn)行引用計(jì)數(shù)，所以這會(huì)對(duì)速度產(chǎn)生一些影響，但它極大地提高了編程的安全性和方便性。以下是引用計(jì)數(shù)的益處：

• 實(shí)現(xiàn)簡(jiǎn)單。
• 易于使用。
• 由于引用是數(shù)據(jù)結(jié)構(gòu)的一部分，所以它有一個(gè)好的緩存位置。

不過，它也有其不足之處：

• 要求您永遠(yuǎn)不要忘記調(diào)用引用計(jì)數(shù)函數(shù)。
• 無法釋放作為循環(huán)數(shù)據(jù)結(jié)構(gòu)的一部分的結(jié)構(gòu)。
• 減緩幾乎每一個(gè)指針的分配。
• 盡管所使用的對(duì)象采用了引用計(jì)數(shù)，但是當(dāng)使用異常處理（比如 try 或 setjmp()/ longjmp()）時(shí)，您必須采取其他方法。
• 需要額外的內(nèi)存來處理引用。
• 引用計(jì)數(shù)占用了結(jié)構(gòu)中的第一個(gè)位置，在大部分機(jī)器中最快可以訪問到的就是這個(gè)位置。
• 在多線程環(huán)境中更慢也更難以使用。

C++ 可以通過使用 智能指針（smart pointers）來容忍程序員所犯的一些錯(cuò)誤，智能指針可以為您處理引用計(jì)數(shù)等指針處理細(xì)節(jié)。不過，如果不得不使用任何先前的不能處理智能指針的代碼（比如對(duì) C 庫的聯(lián)接），實(shí)際上，使用它們的后果通實(shí)比不使用它們更為困難和復(fù)雜。因此，它通常只是有益于純 C++ 項(xiàng)目。如果您想使用智能指針，那么您實(shí)在應(yīng)該去閱讀 Alexandrescu 撰寫的 Modern C++ Design 一書中的“Smart Pointers”那一章。

內(nèi)存池

內(nèi)存池是另一種半自動(dòng)內(nèi)存管理方法。內(nèi)存池幫助某些程序進(jìn)行自動(dòng)內(nèi)存管理，這些程序會(huì)經(jīng)歷一些特定的階段，而且每個(gè)階段中都有分配給進(jìn)程的特定階段的內(nèi)存。例如，很多網(wǎng)絡(luò)服務(wù)器進(jìn)程都會(huì)分配很多針對(duì)每個(gè)連接的內(nèi)存 —— 內(nèi)存的最大生存期限為當(dāng)前連接的存在期。Apache 使用了池式內(nèi)存（pooled memory），將其連接拆分為各個(gè)階段，每個(gè)階段都有自己的內(nèi)存池。在結(jié)束每個(gè)階段時(shí)，會(huì)一次釋放所有內(nèi)存。

在池式內(nèi)存管理中，每次內(nèi)存分配都會(huì)指定內(nèi)存池，從中分配內(nèi)存。每個(gè)內(nèi)存池都有不同的生存期限。在 Apache 中，有一個(gè)持續(xù)時(shí)間為服務(wù)器存在期的內(nèi)存池，還有一個(gè)持續(xù)時(shí)間為連接的存在期的內(nèi)存池，以及一個(gè)持續(xù)時(shí)間為請(qǐng)求的存在期的池，另外還有其他一些內(nèi)存池。因此，如果我的一系列函數(shù)不會(huì)生成比連接持續(xù)時(shí)間更長(zhǎng)的數(shù)據(jù)，那么我就可以完全從連接池中分配內(nèi)存，并知道在連接結(jié)束時(shí)，這些內(nèi)存會(huì)被自動(dòng)釋放。另外，有一些實(shí)現(xiàn)允許注冊(cè) 清除函數(shù)（cleanup functions），在清除內(nèi)存池之前，恰好可以調(diào)用它，來完成在內(nèi)存被清理前需要完成的其他所有任務(wù)（類似于面向?qū)ο笾械奈鰳?gòu)函數(shù)）。

要在自己的程序中使用池，您既可以使用 GNU libc 的 obstack 實(shí)現(xiàn)，也可以使用 Apache 的 Apache Portable Runtime。GNU obstack 的好處在于，基于 GNU 的 Linux 發(fā)行版本中默認(rèn)會(huì)包括它們。Apache Portable Runtime 的好處在于它有很多其他工具，可以處理編寫多平臺(tái)服務(wù)器軟件所有方面的事情。要深入了解 GNU obstack 和 Apache 的池式內(nèi)存實(shí)現(xiàn)，請(qǐng)參閱 參考資料部分中指向這些實(shí)現(xiàn)的文檔的鏈接。

下面的假想代碼列表展示了如何使用 obstack：

            #include <obstack.h>
            #include <stdlib.h>
            /* Example code listing for using obstacks */
            /* Used for obstack macros (xmalloc is
            a malloc function that exits if memory
            is exhausted */
            #define obstack_chunk_alloc xmalloc
            #define obstack_chunk_free free
            /* Pools */
            /* Only permanent allocations should go in this pool */
            struct obstack *global_pool;
            /* This pool is for per-connection data */
            struct obstack *connection_pool;
            /* This pool is for per-request data */
            struct obstack *request_pool;
            void allocation_failed()
            {
            exit(1);
            }
            int main()
            {
            /* Initialize Pools */
            global_pool = (struct obstack *)
            xmalloc (sizeof (struct obstack));
            obstack_init(global_pool);
            connection_pool = (struct obstack *)
            xmalloc (sizeof (struct obstack));
            obstack_init(connection_pool);
            request_pool = (struct obstack *)
            xmalloc (sizeof (struct obstack));
            obstack_init(request_pool);
            /* Set the error handling function */
            obstack_alloc_failed_handler = &allocation_failed;
            /* Server main loop */
            while(1)
            {
            wait_for_connection();
            /* We are in a connection */
            while(more_requests_available())
            {
            /* Handle request */
            handle_request();
            /* Free all of the memory allocated
            * in the request pool
            */
            obstack_free(request_pool, NULL);
            }
            /* We're finished with the connection, time
            * to free that pool
            */
            obstack_free(connection_pool, NULL);
            }
            }
            int handle_request()
            {
            /* Be sure that all object allocations are allocated
            * from the request pool
            */
            int bytes_i_need = 400;
            void *data1 = obstack_alloc(request_pool, bytes_i_need);
            /* Do stuff to process the request */
            /* return */
            return 0;
            }
            

基本上，在操作的每一個(gè)主要階段結(jié)束之后，這個(gè)階段的 obstack 會(huì)被釋放。不過，要注意的是，如果一個(gè)過程需要分配持續(xù)時(shí)間比當(dāng)前階段更長(zhǎng)的內(nèi)存，那么它也可以使用更長(zhǎng)期限的 obstack，比如連接或者全局內(nèi)存。傳遞給 obstack_free() 的 NULL 指出它應(yīng)該釋放 obstack 的全部?jī)?nèi)容。可以用其他的值，但是它們通常不怎么實(shí)用。

使用池式內(nèi)存分配的益處如下所示：

• 應(yīng)用程序可以簡(jiǎn)單地管理內(nèi)存。
• 內(nèi)存分配和回收更快，因?yàn)槊看味际窃谝粋€(gè)池中完成的。分配可以在 O(1) 時(shí)間內(nèi)完成，釋放內(nèi)存池所需時(shí)間也差不多（實(shí)際上是 O(n) 時(shí)間，不過在大部分情況下會(huì)除以一個(gè)大的因數(shù)，使其變成 O(1)）。
• 可以預(yù)先分配錯(cuò)誤處理池（Error-handling pools），以便程序在常規(guī)內(nèi)存被耗盡時(shí)仍可以恢復(fù)。
• 有非常易于使用的標(biāo)準(zhǔn)實(shí)現(xiàn)。

池式內(nèi)存的缺點(diǎn)是：

• 內(nèi)存池只適用于操作可以分階段的程序。
• 內(nèi)存池通常不能與第三方庫很好地合作。
• 如果程序的結(jié)構(gòu)發(fā)生變化，則不得不修改內(nèi)存池，這可能會(huì)導(dǎo)致內(nèi)存管理系統(tǒng)的重新設(shè)計(jì)。
• 您必須記住需要從哪個(gè)池進(jìn)行分配。另外，如果在這里出錯(cuò)，就很難捕獲該內(nèi)存池。

回頁首

垃圾收集

垃圾收集（Garbage collection）是全自動(dòng)地檢測(cè)并移除不再使用的數(shù)據(jù)對(duì)象。垃圾收集器通常會(huì)在當(dāng)可用內(nèi)存減少到少于一個(gè)具體的閾值時(shí)運(yùn)行。通常，它們以程序所知的可用的一組“基本”數(shù)據(jù) —— 棧數(shù)據(jù)、全局變量、寄存器 —— 作為出發(fā)點(diǎn)。然后它們嘗試去追蹤通過這些數(shù)據(jù)連接到每一塊數(shù)據(jù)。收集器找到的都是有用的數(shù)據(jù)；它沒有找到的就是垃圾，可以被銷毀并重新使用這些無用的數(shù)據(jù)。為了有效地管理內(nèi)存，很多類型的垃圾收集器都需要知道數(shù)據(jù)結(jié)構(gòu)內(nèi)部指針的規(guī)劃，所以，為了正確運(yùn)行垃圾收集器，它們必須是語言本身的一部分。

收集器的類型

• 復(fù)制（copying）： 這些收集器將內(nèi)存存儲(chǔ)器分為兩部分，只允許數(shù)據(jù)駐留在其中一部分上。它們定時(shí)地從“基本”的元素開始將數(shù)據(jù)從一部分復(fù)制到另一部分。內(nèi)存新近被占用的部分現(xiàn)在成為活動(dòng)的，另一部分上的所有內(nèi)容都認(rèn)為是垃圾。另外，當(dāng)進(jìn)行這項(xiàng)復(fù)制操作時(shí)，所有指針都必須被更新為指向每個(gè)內(nèi)存條目的新位置。因此，為使用這種垃圾收集方法，垃圾收集器必須與編程語言集成在一起。
• 標(biāo)記并清理（Mark and sweep）：每一塊數(shù)據(jù)都被加上一個(gè)標(biāo)簽。不定期的，所有標(biāo)簽都被設(shè)置為 0，收集器從“基本”的元素開始遍歷數(shù)據(jù)。當(dāng)它遇到內(nèi)存時(shí)，就將標(biāo)簽標(biāo)記為 1。最后沒有被標(biāo)記為 1 的所有內(nèi)容都認(rèn)為是垃圾，以后分配內(nèi)存時(shí)會(huì)重新使用它們。
• 增量的（Incremental）：增量垃圾收集器不需要遍歷全部數(shù)據(jù)對(duì)象。因?yàn)樵谑占陂g的突然等待，也因?yàn)榕c訪問所有當(dāng)前數(shù)據(jù)相關(guān)的緩存問題（所有內(nèi)容都不得不被頁入（page-in）），遍歷所有內(nèi)存會(huì)引發(fā)問題。增量收集器避免了這些問題。
• 保守的（Conservative）：保守的垃圾收集器在管理內(nèi)存時(shí)不需要知道與數(shù)據(jù)結(jié)構(gòu)相關(guān)的任何信息。它們只查看所有數(shù)據(jù)類型，并假定它們 可以全部都是指針。所以，如果一個(gè)字節(jié)序列可以是一個(gè)指向一塊被分配的內(nèi)存的指針，那么收集器就將其標(biāo)記為正在被引用。有時(shí)沒有被引用的內(nèi)存會(huì)被收集，這樣會(huì)引發(fā)問題，例如，如果一個(gè)整數(shù)域中包含一個(gè)值，該值是已分配內(nèi)存的地址。不過，這種情況極少發(fā)生，而且它只會(huì)浪費(fèi)少量?jī)?nèi)存。保守的收集器的優(yōu)勢(shì)是，它們可以與任何編程語言相集成。

Hans Boehm 的保守垃圾收集器是可用的最流行的垃圾收集器之一，因?yàn)樗敲赓M(fèi)的，而且既是保守的又是增量的，可以使用 --enable-redirect-malloc 選項(xiàng)來構(gòu)建它，并且可以將它用作系統(tǒng)分配程序的簡(jiǎn)易替代者（drop-in replacement）（用 malloc/ free 代替它自己的 API）。實(shí)際上，如果這樣做，您就可以使用與我們?cè)谑纠峙涑绦蛑兴褂玫南嗤?LD_PRELOAD 技巧，在系統(tǒng)上的幾乎任何程序中啟用垃圾收集。如果您懷疑某個(gè)程序正在泄漏內(nèi)存，那么您可以使用這個(gè)垃圾收集器來控制進(jìn)程。在早期，當(dāng) Mozilla 嚴(yán)重地泄漏內(nèi)存時(shí)，很多人在其中使用了這項(xiàng)技術(shù)。這種垃圾收集器既可以在 Windows® 下運(yùn)行，也可以在 UNIX 下運(yùn)行。

垃圾收集的一些優(yōu)點(diǎn)：

• 您永遠(yuǎn)不必?fù)?dān)心內(nèi)存的雙重釋放或者對(duì)象的生命周期。
• 使用某些收集器，您可以使用與常規(guī)分配相同的 API。

其缺點(diǎn)包括：

• 使用大部分收集器時(shí)，您都無法干涉何時(shí)釋放內(nèi)存。
• 在多數(shù)情況下，垃圾收集比其他形式的內(nèi)存管理更慢。
• 垃圾收集錯(cuò)誤引發(fā)的缺陷難于調(diào)試。
• 如果您忘記將不再使用的指針設(shè)置為 null，那么仍然會(huì)有內(nèi)存泄漏。

回頁首

結(jié)束語

一切都需要折衷：性能、易用、易于實(shí)現(xiàn)、支持線程的能力等，這里只列出了其中的一些。為了滿足項(xiàng)目的要求，有很多內(nèi)存管理模式可以供您使用。每種模式都有大量的實(shí)現(xiàn)，各有其優(yōu)缺點(diǎn)。對(duì)很多項(xiàng)目來說，使用編程環(huán)境默認(rèn)的技術(shù)就足夠了，不過，當(dāng)您的項(xiàng)目有特殊的需要時(shí)，了解可用的選擇將會(huì)有幫助。下表對(duì)比了本文中涉及的內(nèi)存管理策略。

表 1. 內(nèi)存分配策略的對(duì)比

策略	分配速度	回收速度	局部緩存	易用性	通用性	實(shí)時(shí)可用	SMP 線程友好
定制分配程序	取決于實(shí)現(xiàn)	取決于實(shí)現(xiàn)	取決于實(shí)現(xiàn)	很難	無	取決于實(shí)現(xiàn)	取決于實(shí)現(xiàn)
簡(jiǎn)單分配程序	內(nèi)存使用少時(shí)較快	很快	差	容易	高	否	否
GNU malloc	中	快	中	容易	高	否	中
Hoard	中	中	中	容易	高	否	是
引用計(jì)數(shù)	N/A	N/A	非常好	中	中	是（取決于 malloc 實(shí)現(xiàn)）	取決于實(shí)現(xiàn)
池	中	非常快	極好	中	中	是（取決于 malloc 實(shí)現(xiàn)）	取決于實(shí)現(xiàn)
垃圾收集	中（進(jìn)行收集時(shí)慢）	中	差	中	中	否	幾乎不
增量垃圾收集	中	中	中	中	中	否	幾乎不
增量保守垃圾收集	中	中	中	容易	高	否	幾乎不

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。
  

Web 上的文檔

• GNU C Library 手冊(cè)的 obstacks 部分 提供了 obstacks 編程接口。
  
  
• Apache Portable Runtime 文檔 描述了它們的池式分配程序的接口。
  

• Doug Lea 的 Malloc 是最流行的內(nèi)存分配程序之一。
  
  
• BSD Malloc 用于大部分基于 BSD 的系統(tǒng)中。
  
  
• ptmalloc 起源于 Doug Lea 的 malloc，用于 GLIBC 之中。
  
  
• Hoard 是一個(gè)為多線程應(yīng)用程序優(yōu)化的 malloc 實(shí)現(xiàn)。
  
  
• GNU Memory-Mapped Malloc（GDB 的組成部分） 是一個(gè)基于 mmap() 的 malloc 實(shí)現(xiàn)。
  

• GNU Obstacks（GNU Libc 的組成部分）是安裝最多的池式分配程序，因?yàn)樵诿恳粋€(gè)基于 glibc 的系統(tǒng)中都有它。
  
  
• Apache 的池式分配程序（Apache Portable Runtime 中） 是應(yīng)用最為廣泛的池式分配程序。
  
  
• Squid 有其自己的池式分配程序。
  
  
• NetBSD 也有其自己的池式分配程序。
  
  
• talloc 是一個(gè)池式分配程序，是 Samba 的組成部分。
  

• Loki C++ Library 有很多為 C++ 實(shí)現(xiàn)的通用模式，包括智能指針和一個(gè)定制的小對(duì)象分配程序。
  

• Hahns Boehm Conservative Garbage Collector 是最流行的開源垃圾收集器，它可以用于常規(guī)的 C/C++ 程序。
  

• Marshall Kirk McKusick 和 Michael J. Karels 合著的 A New Virtual Memory Implementation for Berkeley UNIX 討論了 BSD 的 VM 系統(tǒng)。
  
  
• Mel Gorman's Linux VM Documentation 討論了 Linux VM 系統(tǒng)。
  

• Poul-Henning Kamp 撰寫的 Malloc in Modern Virtual Memory Environments 討論的是 malloc 以及它如何與 BSD 虛擬內(nèi)存交互。
  
  
• Berger、McKinley、Blumofe 和 Wilson 合著的 Hoard -- a Scalable Memory Allocator for Multithreaded Environments 討論了 Hoard 分配程序的實(shí)現(xiàn)。
  
  
• Marshall Kirk McKusick 和 Michael J. Karels 合著的 Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel 討論了內(nèi)核級(jí)的分配程序。
  
  
• Doug Lea 撰寫的 A Memory Allocator 給出了一個(gè)關(guān)于設(shè)計(jì)和實(shí)現(xiàn)分配程序的概述，其中包括設(shè)計(jì)選擇與折衷。
  
  
• Emery D. Berger 撰寫的 Memory Management for High-Performance Applications 討論的是定制內(nèi)存管理以及它如何影響高性能應(yīng)用程序。
  

• Doug Lea 撰寫的 Some Storage Management Techniques for Container Classes 描述的是為 C++ 類編寫定制分配程序。
  
  
• Berger、Zorn 和 McKinley 合著的 Composing High-Performance Memory Allocators 討論了如何編寫定制分配程序來加快具體工作的速度。
  
  
• Berger、Zorn 和 McKinley 合著的 Reconsidering Custom Memory Allocation 再次提及了定制分配的主題，看是否真正值得為其費(fèi)心。
  

• Paul R. Wilson 撰寫的 Uniprocessor Garbage Collection Techniques 給出了垃圾收集的一個(gè)基本概述。
  
  
• Benjamin Zorn 撰寫的 The Measured Cost of Garbage Collection 給出了關(guān)于垃圾收集和性能的硬數(shù)據(jù)（hard data）。
  
  
• Hans-Juergen Boehm 撰寫的 Memory Allocation Myths and Half-Truths 給出了關(guān)于垃圾收集的神話（myths）。
  
  
• Hans-Juergen Boehm 撰寫的 Space Efficient Conservative Garbage Collection 是一篇描述他的用于 C/C++ 的垃圾收集器的文章。
  

• 內(nèi)存管理參考 中有很多關(guān)于內(nèi)存管理參考資料和技術(shù)文章的鏈接。
  
  
• 關(guān)于內(nèi)存管理和內(nèi)存層級(jí)的 OOPS Group Papers 是非常好的一組關(guān)于此主題的技術(shù)文章。
  
  
• C++ 中的內(nèi)存管理討論的是為 C++ 編寫定制的分配程序。
  
  
• Programming Alternatives: Memory Management 討論了程序員進(jìn)行內(nèi)存管理時(shí)的一些選擇。
  
  
• 垃圾收集 FAQ 討論了關(guān)于垃圾收集您需要了解的所有內(nèi)容。
  
  
• Richard Jones 的 Garbage Collection Bibliography 有指向任何您想要的關(guān)于垃圾收集的文章的鏈接。
  

• Michael Daconta 撰寫的 C++ Pointers and Dynamic Memory Management 介紹了關(guān)于內(nèi)存管理的很多技術(shù)。
  
  
• Frantisek Franek 撰寫的 Memory as a Programming Concept in C and C++ 討論了有效使用內(nèi)存的技術(shù)與工具，并給出了在計(jì)算機(jī)編程中應(yīng)當(dāng)引起注意的內(nèi)存相關(guān)錯(cuò)誤的角色。
  
  
• Richard Jones 和 Rafael Lins 合著的 Garbage Collection: Algorithms for Automatic Dynamic Memory Management 描述了當(dāng)前使用的最常見的垃圾收集算法。
  
  
• 在 Donald Knuth 撰寫的 The Art of Computer Programming 第 1 卷 Fundamental Algorithms 的第 2.5 節(jié)“Dynamic Storage Allocation”中，描述了實(shí)現(xiàn)基本的分配程序的一些技術(shù)。
  
  
• 在 Donald Knuth 撰寫的 The Art of Computer Programming 第 1 卷 Fundamental Algorithms 的第 2.3.5 節(jié)“Lists and Garbage Collection”中，討論了用于列表的垃圾收集算法。
  
  
• Andrei Alexandrescu 撰寫的 Modern C++ Design 第 4 章“Small Object Allocation”描述了一個(gè)比 C++ 標(biāo)準(zhǔn)分配程序效率高得多的一個(gè)高速小對(duì)象分配程序。
  
  
• Andrei Alexandrescu 撰寫的 Modern C++ Design 第 7 章“Smart Pointers”描述了在 C++ 中智能指針的實(shí)現(xiàn)。
  
  
• Jonathan 撰寫的 Programming from the Ground Up 第 8 章“Intermediate Memory Topics”中有本文使用的簡(jiǎn)單分配程序的一個(gè)匯編語言版本。
  

• 自我管理數(shù)據(jù)緩沖區(qū)內(nèi)存 （developerWorks，2004 年 1 月）略述了一個(gè)用于管理內(nèi)存的自管理的抽象數(shù)據(jù)緩存器的偽 C （pseudo-C）實(shí)現(xiàn)。
  
  
• A framework for the user defined malloc replacement feature （developerWorks，2002 年 2 月）展示了如何利用 AIX 中的一個(gè)工具，使用自己設(shè)計(jì)的內(nèi)存子系統(tǒng)取代原有的內(nèi)存子系統(tǒng)。
  
  
• 掌握 Linux 調(diào)試技術(shù) （developerWorks，2002 年 8 月）描述了可以使用調(diào)試方法的 4 種不同情形：段錯(cuò)誤、內(nèi)存溢出、內(nèi)存泄漏和掛起。
  
  
• 在 處理 Java 程序中的內(nèi)存漏洞 （developerWorks，2001 年 2 月）中，了解導(dǎo)致 Java 內(nèi)存泄漏的原因，以及何時(shí)需要考慮它們。
  
  
• 在 developerWorks Linux 專區(qū)中，可以找到更多為 Linux 開發(fā)人員準(zhǔn)備的參考資料。
  
  
• 從 developerWorks 的 Speed-start your Linux app 專區(qū)中，可以下載運(yùn)行于 Linux 之上的 IBM 中間件產(chǎn)品的免費(fèi)測(cè)試版本，其中包括 WebSphere® Studio Application Developer、WebSphere Application Server、DB2® Universal Database、Tivoli® Access Manager 和 Tivoli Directory Server，查找 how-to 文章和技術(shù)支持。
  
  
• 通過參與 developerWorks blogs 加入到 developerWorks 社區(qū)。
  
  
• 可以在 Developer Bookstore Linux 專欄中定購(gòu) 打折出售的 Linux 書籍。
  

關(guān)于作者

		Jonathan Bartlett 是 Programming from the Ground Up 一書的作者，這本書介紹的是 Linux 匯編語言編程。Jonathan Bartlett 是 New Media Worx 的總開發(fā)師，負(fù)責(zé)為客戶開發(fā) Web、視頻、kiosk 和桌面應(yīng)用程序。您可以通過 johnnyb@eskimo.com 與 Jonathan 聯(lián)系。

??? 一。誰在做Garbage Collection？

??? 一種流行的說法：在C++里，是系統(tǒng)在做垃圾回收；而在Java里，是Java自身在做。

??? 在C++里，釋放內(nèi)存是手動(dòng)處理的，要用delete運(yùn)算符來釋放分配的內(nèi)存。這是流行的說法。確切地說，是應(yīng)用認(rèn)為不需要某實(shí)體時(shí)，就需用delete告訴系統(tǒng)，可以回收這塊空間了。這個(gè)要求，對(duì)編碼者來說，是件很麻煩、很難做到的事。隨便上哪個(gè)BBS，在C/C++版塊里總是有一大堆關(guān)于內(nèi)存泄漏的話題。

??? Java采用一種不同的，很方便的方法：Garbage Collection.垃圾回收機(jī)制放在JVM里。JVM完全負(fù)責(zé)垃圾回收事宜，應(yīng)用只在需要時(shí)申請(qǐng)空間，而在拋棄對(duì)象時(shí)不必關(guān)心空間回收問題。

??? 二。對(duì)象在啥時(shí)被丟棄？

??? 在C++里，當(dāng)對(duì)象離開其作用域時(shí)，該對(duì)象即被應(yīng)用拋棄。

??? 是對(duì)象的生命期不再與其作用域有關(guān)，而僅僅與引用有關(guān)。

??? Java的垃圾回收機(jī)制一般包含近十種算法。對(duì)這些算法中的多數(shù)，我們不必予以關(guān)心。只有其中最簡(jiǎn)單的一個(gè)：引用計(jì)數(shù)法，與編碼有關(guān)。

??? 一個(gè)對(duì)象，可以有一個(gè)或多個(gè)引用變量指向它。當(dāng)一個(gè)對(duì)象不再有任何一個(gè)引用變量指向它時(shí)，這個(gè)對(duì)象就被應(yīng)用拋棄了。或者說，這個(gè)對(duì)象可以被垃圾回收機(jī)制回收了。

??? 這就是說，當(dāng)不存在對(duì)某對(duì)象的任何引用時(shí)，就意味著，應(yīng)用告訴JVM：我不要這個(gè)對(duì)象，你可以回收了。

??? JVM的垃圾回收機(jī)制對(duì)堆空間做實(shí)時(shí)檢測(cè)。當(dāng)發(fā)現(xiàn)某對(duì)象的引用計(jì)數(shù)為0時(shí)，就將該對(duì)象列入待回收列表中。但是，并不是馬上予以銷毀。

??? 三。丟棄就被回收？

??? 該對(duì)象被認(rèn)定為沒有存在的必要了，那么它所占用的內(nèi)存就可以被釋放。被回收的內(nèi)存可以用于后續(xù)的再分配。

??? 但是，并不是對(duì)象被拋棄后當(dāng)即被回收的。JVM進(jìn)程做空間回收有較大的系統(tǒng)開銷。如果每當(dāng)某應(yīng)用進(jìn)程丟棄一個(gè)對(duì)象，就立即回收它的空間，勢(shì)必會(huì)使整個(gè)系統(tǒng)的運(yùn)轉(zhuǎn)效率非常低下。

??? 前面說過，JVM的垃圾回收機(jī)制有多個(gè)算法。除了引用計(jì)數(shù)法是用來判斷對(duì)象是否已被拋棄外，其它算法是用來確定何時(shí)及如何做回收。JVM的垃圾回收機(jī)制要在時(shí)間和空間之間做個(gè)平衡。

??? 因此，為了提高系統(tǒng)效率，垃圾回收器通常只在滿足兩個(gè)條件時(shí)才運(yùn)行：即有對(duì)象要回收且系統(tǒng)需要回收。切記垃圾回收要占用時(shí)間，因此，Java運(yùn)行時(shí)系統(tǒng)只在需要的時(shí)候才使用它。因此你無法知道垃圾回收發(fā)生的精確時(shí)間。

??? 四。沒有引用變量指向的對(duì)象有用嗎？

??? 前面說了，沒掛上引用變量的對(duì)象是被應(yīng)用丟棄的，這意味著，它在堆空間里是個(gè)垃圾，隨時(shí)可能被JVM回收。

??? 不過，這里有個(gè)不是例外的例外。對(duì)于一次性使用的對(duì)象（有些書稱之為臨時(shí)對(duì)象），可以不用引用變量指向它。舉個(gè)最簡(jiǎn)單也最常見的例子：

??? System.out.println（“I am Java！”）；

??? 就是創(chuàng)建了一個(gè)字符串對(duì)象后，直接傳遞給println（）方法。

??? 五。應(yīng)用能干預(yù)垃圾回收嗎？

??? 許多人對(duì)Java的垃圾回收不放心，希望在應(yīng)用代碼里控制JVM的垃圾回收運(yùn)作。這是不可能的事。對(duì)垃圾回收機(jī)制來說，應(yīng)用只有兩個(gè)途徑發(fā)消息給JVM.第一個(gè)前面已經(jīng)說了，就是將指向某對(duì)象的所有引用變量全部移走。這就相當(dāng)于向JVM發(fā)了一個(gè)消息：這個(gè)對(duì)象不要了。第二個(gè)是調(diào)用庫方法System.gc（），多數(shù)書里說調(diào)用它讓Java做垃圾回收。

??? 第一個(gè)是一個(gè)告知，而調(diào)用System.gc（）也僅僅是一個(gè)請(qǐng)求。JVM接受這個(gè)消息后，并不是立即做垃圾回收，而只是對(duì)幾個(gè)垃圾回收算法做了加權(quán)，使垃圾回收操作容易發(fā)生，或提早發(fā)生，或回收較多而已。

??? 希望JVM及時(shí)回收垃圾，是一種需求。其實(shí)，還有相反的一種需要：在某段時(shí)間內(nèi)最好不要回收垃圾。要求運(yùn)行速度最快的實(shí)時(shí)系統(tǒng)，特別是嵌入式系統(tǒng)，往往希望如此。

??? Java的垃圾回收機(jī)制是為所有Java應(yīng)用進(jìn)程服務(wù)的，而不是為某個(gè)特定的進(jìn)程服務(wù)的。因此，任何一個(gè)進(jìn)程都不能命令垃圾回收機(jī)制做什么、怎么做或做多少。

??? 六。對(duì)象被回收時(shí)要做的事

??? 一個(gè)對(duì)象在運(yùn)行時(shí)，可能會(huì)有一些東西與其關(guān)連。因此，當(dāng)對(duì)象即將被銷毀時(shí)，有時(shí)需要做一些善后工作。可以把這些操作寫在finalize（）方法（常稱之為終止器）里。

??? protected void finalize（）

??? {

??? // finalization code here

??? }

??? 這個(gè)終止器的用途類似于C++里的析構(gòu)函數(shù)，而且都是自動(dòng)調(diào)用的。但是，兩者的調(diào)用時(shí)機(jī)不一樣，使兩者的表現(xiàn)行為有重大區(qū)別。C++的析構(gòu)函數(shù)總是當(dāng)對(duì)象離開作用域時(shí)被調(diào)用。這就是說，C++析構(gòu)函數(shù)的調(diào)用時(shí)機(jī)是確定的，且是可被應(yīng)用判知的。但是，Java終止器卻是在對(duì)象被銷毀時(shí)。由上所知，被丟棄的對(duì)象何時(shí)被銷毀，應(yīng)用是無法獲知的。而且，對(duì)于大多數(shù)場(chǎng)合，被丟棄對(duì)象在應(yīng)用終止后仍未銷毀。

??? 在編碼時(shí)，考慮到這一點(diǎn)。譬如，某對(duì)象在運(yùn)作時(shí)打開了某個(gè)文件，在對(duì)象被丟棄時(shí)不關(guān)閉它，而是把文件關(guān)閉語句寫在終止器里。這樣做對(duì)文件操作會(huì)造成問題。如果文件是獨(dú)占打開的，則其它對(duì)象將無法訪問這個(gè)文件。如果文件是共享打開的，則另一訪問該文件的對(duì)象直至應(yīng)用終結(jié)仍不能讀到被丟棄對(duì)象寫入該文件的新內(nèi)容。

??? 至少對(duì)于文件操作，編碼者應(yīng)認(rèn)清Java終止器與C++析構(gòu)函數(shù)之間的差異。

??? 那么，當(dāng)應(yīng)用終止，會(huì)不會(huì)執(zhí)行應(yīng)用中的所有finalize（）呢？據(jù)Bruce Eckel在Thinking in Java里的觀點(diǎn)：“到程序結(jié)束的時(shí)候，并非所有收尾模塊都會(huì)得到調(diào)用”。這還僅僅是指應(yīng)用正常終止的場(chǎng)合，非正常終止呢？

??? 因此，哪些收尾操作可以放在finalize（）里，是需要酌酎的。

什么是UDP協(xié)議

　　UDP協(xié)議的全稱是用戶數(shù)據(jù)報(bào)，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包。在OSI模型中，在第四層——傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)報(bào)分組、組裝和不能對(duì)數(shù)據(jù)包的排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無法得知其是否安全完整到達(dá)的。

　　為什么要使用UDP

　　在選擇使用協(xié)議的時(shí)候，選擇UDP必須要謹(jǐn)慎。在網(wǎng)絡(luò)質(zhì)量令人不十分滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會(huì)比較嚴(yán)重。但是由于UDP的特性：它不屬于連接型協(xié)議，因而具有資源消耗小，處理速度快的優(yōu)點(diǎn)，所以通常音頻、視頻和普通數(shù)據(jù)在傳送時(shí)使用UDP較多，因?yàn)樗鼈兗词古紶杹G失一兩個(gè)數(shù)據(jù)包，也不會(huì)對(duì)接收結(jié)果產(chǎn)生太大影響。比如我們聊天用的ICQ和OICQ就是使用的UDP協(xié)議。

　　在Java中操縱UDP

　　使用位于JDK中Java.net包下的DatagramSocket和DatagramPacket類，可以非常方便地控制用戶數(shù)據(jù)報(bào)文。

　　在描述它們之前，必須了解位于同一個(gè)位置的InetAddress類。InetAddress實(shí)現(xiàn)了Java.io. Serializable接口，不允許繼承。它用于描述和包裝一個(gè)Internet IP地址，通過三個(gè)方法返回InetAddress實(shí)例：

　　getLocalhost()：返回封裝本地地址的實(shí)例。

　　getAllByName(String host)：返回封裝Host地址的InetAddress實(shí)例數(shù)組。

　　getByName(String host)：返回一個(gè)封裝Host地址的實(shí)例。其中，Host可以是域名或者是一個(gè)合法的IP地址。

　　DatagramSocket類用于創(chuàng)建接收和發(fā)送UDP的Socket實(shí)例。和Socket類依賴SocketImpl類一樣，DatagramSocket類的實(shí)現(xiàn)也依靠專門為它設(shè)計(jì)的DatagramScoketImplFactory類。DatagramSocket類有3個(gè)構(gòu)建器：

　　DatagramSocket()：創(chuàng)建實(shí)例。這是個(gè)比較特殊的用法，通常用于客戶端編程，它并沒有特定監(jiān)聽的端口，僅僅使用一個(gè)臨時(shí)的。

　　DatagramSocket(int port)：創(chuàng)建實(shí)例，并固定監(jiān)聽Port端口的報(bào)文。

　　DatagramSocket(int port, InetAddress localAddr)：這是個(gè)非常有用的構(gòu)建器，當(dāng)一臺(tái)機(jī)器擁有多于一個(gè)IP地址的時(shí)候，由它創(chuàng)建的實(shí)例僅僅接收來自LocalAddr的報(bào)文。

　　值得注意的是，在創(chuàng)建DatagramSocket類實(shí)例時(shí)，如果端口已經(jīng)被使用，會(huì)產(chǎn)生一個(gè)SocketException的異常拋出，并導(dǎo)致程序非法終止，這個(gè)異常應(yīng)該注意捕獲。DatagramSocket類最主要的方法有4個(gè)：

　　Receive(DatagramPacket d)：接收數(shù)據(jù)報(bào)文到d中。receive方法產(chǎn)生一個(gè)“阻塞”。

　　Send(DatagramPacket d)：發(fā)送報(bào)文d到目的地。

　　SetSoTimeout(int timeout)：設(shè)置超時(shí)時(shí)間，單位為毫秒。

　　Close()：關(guān)閉DatagramSocket。在應(yīng)用程序退出的時(shí)候，通常會(huì)主動(dòng)釋放資源，關(guān)閉Socket，但是由于異常地退出可能造成資源無法回收。所以，應(yīng)該在程序完成時(shí)，主動(dòng)使用此方法關(guān)閉Socket，或在捕獲到異常拋出后關(guān)閉Socket。

　　“阻塞”是一個(gè)專業(yè)名詞，它會(huì)產(chǎn)生一個(gè)內(nèi)部循環(huán)，使程序暫停在這個(gè)地方，直到一個(gè)條件觸發(fā)。

　　DatagramPacket類用于處理報(bào)文，它將Byte數(shù)組、目標(biāo)地址、目標(biāo)端口等數(shù)據(jù)包裝成報(bào)文或者將報(bào)文拆卸成Byte數(shù)組。應(yīng)用程序在產(chǎn)生數(shù)據(jù)包是應(yīng)該注意，TCP/IP規(guī)定數(shù)據(jù)報(bào)文大小最多包含65507個(gè)，通常主機(jī)接收548個(gè)字節(jié)，但大多數(shù)平臺(tái)能夠支持8192字節(jié)大小的報(bào)文。DatagramPacket類的構(gòu)建器共有4個(gè)：

　　DatagramPacket(byte[] buf, int length, InetAddress addr, int port)：從Buf數(shù)組中，取出Length長(zhǎng)的數(shù)據(jù)創(chuàng)建數(shù)據(jù)包對(duì)象，目標(biāo)是Addr地址，Port端口。

　　DatagramPacket(byte[] buf, int offset, int length, InetAddress address, int port)：從Buf數(shù)組中，取出Offset開始的、Length長(zhǎng)的數(shù)據(jù)創(chuàng)建數(shù)據(jù)包對(duì)象，目標(biāo)是Addr地址，Port端口。

　　DatagramPacket(byte[] buf, int offset, int length)：將數(shù)據(jù)包中從Offset開始、Length長(zhǎng)的數(shù)據(jù)裝進(jìn)Buf數(shù)組。

　　DatagramPacket(byte[] buf, int length)：將數(shù)據(jù)包中Length長(zhǎng)的數(shù)據(jù)裝進(jìn)Buf數(shù)組。

　　DatagramPacket類最重要的方法就是getData()了，它從實(shí)例中取得報(bào)文的Byte數(shù)組編碼。

　　★簡(jiǎn)單的實(shí)例說明

{接收數(shù)據(jù)的服務(wù)器}
byte[] buf = new byte[1000];
DatagramSocket ds = new DatagramSocket(12345);
//開始監(jiān)視12345端口
DatagramPacket ip = new DatagramPacket(buf, buf.length);
//創(chuàng)建接收數(shù)據(jù)報(bào)的實(shí)例
while (true)
　　{
　　ds.receive(ip);
　　//阻塞，直到收到數(shù)據(jù)報(bào)后將數(shù)據(jù)裝入IP中
　　System.out.println(new String(buf));
　　}
　　{發(fā)送數(shù)據(jù)的客戶端}
　　InetAddress target = InetAddress.getByName(“www.xxx.com“);
　　//得到目標(biāo)機(jī)器的地址實(shí)例
　　DatagramSocket ds = new DatagramSocket(9999);
　　//從9999端口發(fā)送數(shù)據(jù)報(bào)
　　String hello = “Hello, I am come in!”;
　　//要發(fā)送的數(shù)據(jù)
　　byte[] buf = hello.getBytes();
　　//將數(shù)據(jù)轉(zhuǎn)換成Byte類型
　　op = new DatagramPacket(buf, buf.length, target, 12345);
　　//將BUF緩沖區(qū)中的數(shù)據(jù)打包
　　ds.send(op);
　　//發(fā)送數(shù)據(jù)
　　ds.close();
　　//關(guān)閉連接

public static void main(String[] args) {
????// This list is intended to hold only strings.
????// The compiler doesn't know that so we have to remember ourselves.
????List wordlist = new ArrayList();??

????// Oops! We added a String[] instead of a String.
????// The compiler doesn't know that this is an error.
????wordlist.add(args);

????// Since List can hold arbitrary objects, the get() method returns
????// Object.??Since the list is intended to hold strings, we cast the
????// return value to String but get a ClassCastException because of
????// the error above.
????String word = (String)wordlist.get(0);
}

public static void main(String[] args) {
????// This list can only hold String objects
????List<String> wordlist = new ArrayList<String>();

????// args is a String[], not String, so the compiler won't let us do this
????wordlist.add(args);??// Compilation error!

????// We can do this, though.??
????// Notice the use of the new for/in looping statement
????for(String arg : args) wordlist.add(arg);

????// No cast is required.??List<String>.get() returns a String.
????String word = wordlist.get(0);
}

public static void main(String[] args) {
????// A map from strings to their position in the args[] array
????Map<String,Integer> map = new HashMap<String,Integer>();

????// Note that we use autoboxing to wrap i in an Integer object.
????for(int i=0; i < args.length; i++) map.put(args[i], i);??

????// Find the array index of a word.??Note no cast is required!
????Integer position = map.get("hello");

????// We can also rely on autounboxing to convert directly to an int,
????// but this throws a NullPointerException if the key does not exist 
????// in the map
????int pos = map.get("world");
}

// Look at all those nested angle brackets!
Map<String, List<List<int[]>>> map = getWeirdMap();

// The compiler knows all the types and we can write expressions
// like this without casting.??We might still get NullPointerException
// or ArrayIndexOutOfBounds at runtime, of course.
int value = map.get(key).get(0).get(0)[0];

// Here's how we break that expression down step by step.
List<List<int[]>> listOfLists = map.get(key);
List<int[]> listOfIntArrays = listOfLists.get(0);
int[] array = listOfIntArrays.get(0);
int element = array[0];

List<String> words = // ...initialized elsewhere...
Iterator<String> iterator = words.iterator();
String firstword = iterator.next();

List l = new ArrayList();
l.add("hello");??
l.add(new Integer(123));
Object o = l.get(0);

List<Object> l = new ArrayList<Object>();
l.add("hello");??
l.add(123);??????????????// autoboxing
Object o = l.get(0);

ArrayList<Integer> l = new ArrayList<Integer>();
List<Integer> m = l;????????????????????????????// okay
Collection<Integer> n = l;??????????????????????// okay
ArrayList<Number> o = l;????????????????????????// error
Collection<Object> p = (Collection<Object>)l;?? // error, even with cast

List<Integer> li = new ArrayList<Integer>();
li.add(123);

// The line below will not compile.??But for the purposes of this
// thought-experiment, assume that it does compile and see how much
// trouble we get ourselves into.
List<Object> lo = li;??

// Now we can retrieve elements of the list as Object instead of Integer
Object number = lo.get(0);

// But what about this?
lo.add("hello world");

// If the line above is allowed then the line below throws ClassCastException
Integer i = li.get(1);??// Can't cast a String to Integer!

// Here's a basic parameterized list.
List<Integer> li = new ArrayList<Integer>();

// It is legal to assign a parameterized type to a nonparameterized variable
List l = li;?? 

// This line is a bug, but it compiles and runs.
// The Java 5.0 compiler will issue an unchecked warning about it.
// If it appeared as part of a legacy class compiled with Java 1.4, however,
// then we'd never even get the warning.??
l.add("hello");

// This line compiles without warning but throws ClassCastException at runtime.
// Note that the failure can occur far away from the actual bug.
Integer i = li.get(0);

// Here's a basic parameterized list.
List<Integer> li = new ArrayList<Integer>();

// Wrap it for runtime type safety
List<Integer> cli = Collections.checkedList(li, Integer.class);

// Now widen the checked list to the raw type
List l = cli;?? 

// This line compiles but fails at runtime with a ClassCastException.
// The exception occurs exactly where the bug is, rather than far away
l.add("hello");

String[] words = new String[10];
Object[] objs = words;
objs[0] = 1;??// 1 autoboxed to an Integer, throws ArrayStoreException

List<String>[] wordlists = new ArrayList<String>[10];
ArrayList<Integer> ali = new ArrayList<Integer>();
ali.add(123);
Object[] objs = wordlists;
objs[0] = ali;?????????????????????? // No ArrayStoreException
String s = wordlists[0].get(0);??????// ClassCastException!

public static void printList(PrintWriter out, List list) {
????for(int i=0, n=list.size(); i < n; i++) {
????????if (i > 0) out.print(", ");
????????out.print(list.get(i).toString());
????}
}



在Java5.0中，List是一個(gè)泛型類型，如果我們?cè)噲D編譯這個(gè)方法，我們將會(huì)得到unchecked警告。為了解決這些警告，您可能需要這樣來修改這個(gè)方法：

public static void printList(PrintWriter out, List<Object> list) {
????for(int i=0, n=list.size(); i < n; i++) {
????????if (i > 0) out.print(", ");
????????out.print(list.get(i).toString());
????}
}

public static void printList(PrintWriter out, List<?> list) {
????for(int i=0, n=list.size(); i < n; i++) {
????????if (i > 0) out.print(", ");
????????Object o = list.get(i);
????????out.print(o.toString());
????}
}

List<Object> l = new ArrayList<Object>();

public static double sumList(List<?> list) {
????double total = 0.0;
????for(Object o : list) {
????????Number n = (Number) o;??// A cast is required and may fail
????????total += n.doubleValue();
????}
????return total;
}

public static double sumList(List<? extends Number> list) {
????double total = 0.0;
????for(Number n : list) total += n.doubleValue();
????return total;
}

??? Bruce Tate并不是作為一個(gè)局外者寫就《超越Java》這邊書的。他的顧問公司專注于Java 持久化框架和輕量級(jí)開發(fā)方法，同時(shí)他也是這些流行的Java圖書的作者， Spring： A Developer's Notebook， Better， Faster， Lighter Java， 以及 Bitter Java.

??? 1，在《超越Java》中你花費(fèi)了大量的時(shí)間在Ruby上面，看起來是它像在你說那些將超越Java競(jìng)爭(zhēng)者中出類拔萃。你覺得是什么使Ruby比 PHP，Python這類語言優(yōu)越？

??? 這些都是好語言，但是都有一些缺點(diǎn)。對(duì)大型應(yīng)用，PHP和Perl不能連續(xù)地產(chǎn)生可讀的代碼。Lisp，Python和Smalltalk這些就缺少了偉大語言好像應(yīng)該擁有的催化劑。Ruby是一種好語言，和催化劑（Rails）提供了引人注目得新價(jià)值（以效率的角度）以及還在飛速地增長(zhǎng)。Ruby不一定是最好的語言，但是它將是我所見過最有可能的。Ruby不大可能在委員會(huì)那里超過Java.它很有可能首先在一個(gè)更小但是卻重要的環(huán)境中取得好成績(jī)。這個(gè)環(huán)境也就是一個(gè)有web UI大的胖關(guān)系數(shù)據(jù)庫。

??? 2，是否Rails就意味著Ruby？其他語言包括Java難道就不能實(shí)現(xiàn)同樣的思想？

??? 如今，Rails就是超過象Netscape之類語言的催化劑，具有Java一樣的功能，可通過網(wǎng)絡(luò)實(shí)現(xiàn)應(yīng)用的傳送。但是我認(rèn)為Rails很有可能僅僅是Ruby元編程框架浪潮的第一波。

??? 3，你的書中很多都基于典型的“將一個(gè)web接口連接到數(shù)據(jù)庫”場(chǎng)景，Ruby的成功案例看上去也僅僅是一兩個(gè)開發(fā)人員的小項(xiàng)目。但是你也承認(rèn)了Java的重量級(jí)企業(yè)框架對(duì)一些項(xiàng)目的價(jià)值（即大型系統(tǒng)上的大型應(yīng)用）。什么情況下一個(gè)項(xiàng)目對(duì)于RoR來說過于大的呢？如果一個(gè)RoR在那方面的特性發(fā)展緩慢呢？

??? 有Ruby和小團(tuán)隊(duì)你可以做很多事情。基礎(chǔ)代碼幾乎都是一個(gè)人寫就的，但卻關(guān)乎整個(gè)公司的生計(jì)。在一些主要的公司開始進(jìn)行認(rèn)真的嘗試之前，我們不知道你可以利用ruby或者rails到什么程度。其中一個(gè)最吸引我的事情是經(jīng)濟(jì)的規(guī)模，更小的規(guī)模。萬一生產(chǎn)力的數(shù)字是真實(shí)的呢？萬一確實(shí)可以得到5X的增長(zhǎng)？那么你可以在一個(gè)部門內(nèi)劃分工作，將工作劃分給團(tuán)隊(duì)中的一個(gè)。交流將很少會(huì)成為問題。管理和疏忽也很少會(huì)成為問題了。我們都知道對(duì)于一間公司增長(zhǎng)， tipping points意味著什么。因?yàn)樵黾訙贤ê凸芾淼募?jí)別會(huì)產(chǎn)生很多的障礙， 所以一間公司增長(zhǎng)要超過1，5，10，40，甚至100倍是很困難的。但是，在這一點(diǎn)上， Ruby on Rails的可擴(kuò)展性是非常的好。

??? 4，你是否看到Java開發(fā)人員轉(zhuǎn)向Ruby嗎，還是Ruby將會(huì)給新一代的開發(fā)人員采用？

??? 我覺得兩者都有可能。有開發(fā)人員不能容忍學(xué)習(xí)servlets， Spring， XML， Hibernate， Struts 然后還要學(xué)習(xí)一些 UI 粘合的框架。在Rails中，他們將會(huì)完全給釋放出來。同時(shí)也有Java開發(fā)人員已經(jīng)在尋找更加優(yōu)勢(shì)的方法，他們發(fā)現(xiàn)了Ruby on Rails.接受了Rails的Java夢(mèng)想家們的數(shù)目是令人驚愕的，他們有Thought Works，James Duncan Davidson，Stuart Halloway 更有 David Geary.

??? 5，難道Java本身就不能做一些事情來維持它的杰出地位？如果過于復(fù)雜和膨脹，什么可以阻止開發(fā)人員倒退到j(luò)dk 1.4？

??? Java將會(huì)繼續(xù)處于頂峰，并在企業(yè)應(yīng)用上保持良好的表現(xiàn)，但是時(shí)間不會(huì)停滯不前。在某種意味上它終將會(huì)給替代。我們將需要一個(gè)更高級(jí)別的抽象。我認(rèn)為我們最好的希望就是在JVM上做充足的投入，更好地支持動(dòng)態(tài)語言， 擁抱新的事物，對(duì)于舊有的java代碼，則最好是保留保守的態(tài)度。

??? 6，我們應(yīng)該期望Ruby在其他領(lǐng)域引起轟動(dòng)？如果對(duì)于開發(fā)web應(yīng)用它是如此不錯(cuò)，假如Ruby有的可以使用的合適的UI框架，會(huì)不會(huì)在桌面應(yīng)用也實(shí)用呢？

??? 現(xiàn)在說什么還為時(shí)過早。如今，盡管Ruby是有催化作用（Rails）的語言，但是它僅僅是一個(gè)候選。以后將會(huì)發(fā)生什么？我想誰也不知道。

??? James Duncan Davidson：嘗試新事務(wù)

??? 如果你使用Tomcat或者Ant（認(rèn)真地說，什么Java開發(fā)人員什么使用過？）那么你就熟悉了James Duncan Davidson的工作了。在Sun，他致力把這些項(xiàng)目開源并且把他們捐獻(xiàn)給Apache基金會(huì)。并且他也編寫了Servlet API的最初兩個(gè)版本，還有處理XML的Java API.離開Sun之后，他做起了Mac OS 的X開發(fā)。編寫《Running Mac OS X Panther》和參與編寫了《Running Mac OS X Tiger》，《 Mac OS X Panther Hacks》，《 Cocoa in a Nutshell》和《Learning Cocoa with Objective-C， 2nd Edition》

??? 1，上一次我們見到你的時(shí)候，你還是那個(gè)《Mac desktop apps in Cocoa》家伙。而現(xiàn)在，我在你的blog上看到你已經(jīng)深深地陷入了Rails.那是什么回事？

??? 我當(dāng)時(shí)窮的要命和急切地需要錢。那時(shí)我剛剛買了一幢新房，并且抵押付款期限就快到期了――噢，等會(huì)，你想我認(rèn)真點(diǎn)嗎？好吧，事實(shí)是我和我的幾個(gè)朋友已經(jīng)一直在想一起工作一段時(shí)間了。當(dāng)恰當(dāng)?shù)臅r(shí)機(jī)到的時(shí)候，我們給項(xiàng)目做了技術(shù)評(píng)估，Rails成了首選。那時(shí)我還沒用過Rails或者Ruby.但是我是不會(huì)讓小小的需要學(xué)習(xí)阻礙我去做那個(gè)項(xiàng)目的。今年我已經(jīng)學(xué)習(xí)了三種，可能四種語言了。我不再相信一種語言可以做任何事了。如果我需要學(xué)習(xí)一些新知識(shí)去一些事情，我將全力以赴去學(xué)好它。

??? 2，你對(duì)Rails有什么看法？

??? 主要是簡(jiǎn)單性。完成事情的容易程度。我做的那個(gè)應(yīng)用的第一個(gè)項(xiàng)目原來是一個(gè)基于Java的web應(yīng)用。每個(gè)人都知道一定會(huì)有一種更好，更快，更容易的方法的。Ruby一直都是一種好語言――并且是一種有趣的語言――因此建立于它之上的這個(gè)框架，它應(yīng)得到關(guān)注。

??? 3，Ruby的晦澀和Rails的新穎對(duì)客戶來說會(huì)不會(huì)是一個(gè)問題？

??? 不全是。如今事實(shí)上恰恰相反。有太多潛在的工作， 缺并沒有足夠的人在真正地開發(fā)Ruby on Rails應(yīng)用。

??? 4，為什么Ruby會(huì)如此特殊？難道Rails就不能在其他語言中實(shí)現(xiàn)？難道它就不能給Java實(shí)現(xiàn)？

??? 很少有其他語言可以完成Rails，或者像Rails那樣的。Java不在他們之列。Rails從Ruby中獲取了一些妙不可言的東西，嘗試用另一種語言復(fù)制它不僅是對(duì)Rails所做的是一個(gè)浪費(fèi)，對(duì)其他語言來說也是一個(gè)浪費(fèi)。但是它的概念一定會(huì)在其他非常動(dòng)態(tài)的，動(dòng)態(tài)類型語言中得到很好的應(yīng)用。

??? 確實(shí)，我很興奮的看到其他項(xiàng)目正實(shí)現(xiàn)一些從Rails衍生的主意到其他平臺(tái)中。例如作為一個(gè)Python里的Rails版本，Django得到了一些固定的發(fā)展。但是，實(shí)際上它是Python自己的龐然大物，它如何成長(zhǎng)將會(huì)非常有趣。

??? 現(xiàn)在，我已經(jīng)說過了你不能用Java來實(shí)現(xiàn)Rails.但卻并不意味著你不能用Java做一些同樣優(yōu)秀的東西。Java的力量可以以一種有趣的，神奇方式應(yīng)用到一種全新的框架上。只是還沒人做那些事情。每個(gè)人都對(duì)J2EE這個(gè)糕點(diǎn)趨之若騖，以致于沒人以一種更加激烈，更加動(dòng)態(tài)的方式來重新考慮問題。盡管有人提出一個(gè)基于Java的殺手級(jí)的框架可以與Rails做同樣多工作， 它一定也不能做的象Rails一樣。

??? 5，具有良好設(shè)計(jì)的Java應(yīng)用能夠很好地支持特性的擴(kuò)展――設(shè)計(jì)好你的類和包，那么你的心情將舒暢好長(zhǎng)的一段時(shí)間。能否有團(tuán)隊(duì)編寫出一個(gè)真正大型的Ruby應(yīng)用？它是否具可維護(hù)性？或者還是RoR只能小打小鬧？

??? 設(shè)計(jì)良好的應(yīng)用無論是以何種語言編寫的都能夠很好地支持特性的擴(kuò)展。糟糕的設(shè)計(jì)無論是何種語言就不能了。同時(shí)也有了如何才是大型應(yīng)用的定義的問題。我用Ruby寫的第一個(gè)rails應(yīng)用部署到生產(chǎn)也不夠5，000行代碼，但是我之前用其他語言編寫的同樣大小的應(yīng)用卻達(dá)到了50，000行代碼，所以如何定義大型是個(gè)問題。

??? 有團(tuán)隊(duì)可以編寫一個(gè)可以支持大量特性，運(yùn)行良好，時(shí)間上具備可維護(hù)性的Ruby on rails應(yīng)用嗎？是的，毫無疑問。在使用了Ruby on Rails一段時(shí)間后，我將有信心用Rails解決任何尺寸的web應(yīng)用問題。但是，那是因?yàn)槲以谒厦婊ㄙM(fèi)了一些時(shí)間，認(rèn)識(shí)到編寫一個(gè)具有良好設(shè)計(jì)的應(yīng)用是有可能的。

??? 也就是說，很有可能現(xiàn)在正有幾十個(gè)垃圾的Ruby on rails應(yīng)用在編寫中。幾百或者幾千個(gè)都有可能。如果你不知道你正在做什么，你將會(huì)編寫一個(gè)垃圾的應(yīng)用。

??? 6，那么我們回到了web應(yīng)用，你可以在桌面上使用ruby，或者我們是否一直要用C#，面向?qū)ο驝還是OS服務(wù)商支持的語言編寫UI？

??? 嗯，我的生活的一部分就是回到web應(yīng)用。它對(duì)我來說是一個(gè)很好的還環(huán)境，因?yàn)樽詮?994年開始我就一直在做基于web的工作。但是現(xiàn)在我將開發(fā)基于桌面的應(yīng)用。而且人們對(duì)桌面應(yīng)用的需求還很大。我可不想要一個(gè)網(wǎng)絡(luò)的office.你也不想把一些象Aperture的東西建造成一個(gè)web應(yīng)用吧。

??? 你現(xiàn)在可以使用Ruby去建造一個(gè)引人注目的桌面應(yīng)用嗎？不，相關(guān)的工具包還不存在。但是如果存在了恰當(dāng)?shù)墓ぞ甙D―這是有可能的。那就沒有什么東西可以阻止它成為一個(gè)好的桌面應(yīng)用語言了。那是說，我已經(jīng)發(fā)現(xiàn)利用平臺(tái)的最好的方法就是盡量的本地化-貼近平臺(tái)，不管它是一個(gè)操作系統(tǒng)或者還是一個(gè)web應(yīng)用框架。當(dāng)我在Mac上的桌面工作，我需要寫面向?qū)ο驝和Cocoa.當(dāng)我用Rails的web工作，那意味著使用Ruby.而對(duì)于操作系統(tǒng)方面的工作，我需要用到C和shell.在這個(gè)討論中不會(huì)只有唯一的答案。

??? 我認(rèn)為這就是最近對(duì)Ruby on Rails關(guān)注和屏棄以有色Java眼鏡看待世界的真正勝利。Ruby并不會(huì)成為下一個(gè)Java，完全不。而是Ruby on Rails將會(huì)幫助打破了這樣的一個(gè)觀點(diǎn)—— “只有一個(gè)正確的方法”，不是的。解決問題的方法有千百條。真正的，他們中沒有一個(gè)是明顯的勝者。只有解決方案有優(yōu)勢(shì)的位置。

??? 我想就像我們?cè)谄渲泄ぷ鳎燥埡途幼〉慕ㄖ镆粯印Ｒ恍┙ㄖ镒詈檬怯盟嗪弯摻钪臁Ｆ渌氖怯闷鲋＿€有其他的最好是用木材，并且那樣做是有理由的。沒有人會(huì)跳起來說“所有的建筑物一定要用磚頭筑造！”，那樣太愚蠢了！同樣的道理，不是所以的應(yīng)用都應(yīng)該要用Ruby on Rails或者Django或者J2EE或者Perl來編寫的。對(duì)于任何一個(gè)特定的工作都有大量的工具。還有新的工具等待去發(fā)掘呢。訣竅就是決定最優(yōu)秀的那個(gè)。

??? 讓我們從夸夸其談回到你的問題：在web應(yīng)用的范疇，很容易出現(xiàn)一個(gè)新的框架的，因?yàn)槟悴⒉皇桥c視頻卡，GUI和應(yīng)用在上面跑的整個(gè)系統(tǒng)之類打交道。除非是你愿意開發(fā)一個(gè)自己的框架，你必須面對(duì)選擇使用哪個(gè)框架的選擇。在桌面上也是同樣的道理。你可以創(chuàng)建你自己的框架，做任何你想要的做的，但是該建議卻不比你自己為web創(chuàng)建一個(gè)新框架容易。

??? Robert Cooper：帶上利器

??? ONJava的博客Robert Cooper最近在他的blog上撰寫了“It's the End of the World as We Know It."”來回應(yīng)一些“Java時(shí)代末日”的言論。Cooper是亞特蘭大地區(qū)致力于企業(yè)集成和web/web服務(wù)應(yīng)用的J2EE開發(fā)人員，同時(shí)也是資訊和娛樂站點(diǎn)screaming-penguin.com的經(jīng)營(yíng)者。

??? 1，你曾經(jīng)說過“長(zhǎng)期以來‘企業(yè)級(jí)’Java一直未能逃脫的一個(gè)很悲哀的事實(shí)是500個(gè)應(yīng)用才需要‘企業(yè)級(jí)’的功能。”為什么Java開發(fā)人員采用了比他們實(shí)際需要更加復(fù)雜的框架？

??? 好的，有一些因素導(dǎo)致了這樣現(xiàn)象。一個(gè)是“buzzword compliance”。 你想使用你“應(yīng)該”要使用的東西。我記得在99年一些大項(xiàng)目采用了entity bean作為數(shù)據(jù)模型，但是我們很快發(fā)現(xiàn)了性能是如此的恐怖以致于我們最終又轉(zhuǎn)到了手寫的DAO層。

??? 最近對(duì)javax.persistence的修改，一定程度也表明了，EJB的失敗一直都是缺乏不同級(jí)別的支持。理想的情況是，如果我僅需要基本的，簡(jiǎn)單的ORM-類型功能，我就能夠很快的得到。如果我想深入真正復(fù)雜的東西，給我一個(gè)“更深層”的有分布式事務(wù)的視圖。然而，盡管在那樣高的層次上，在EJB1.1/1.2的世界里，看看你需要多少行代碼1）從JNDI獲得Home存根，2）做一個(gè)find by，3）做改變，4）提交事務(wù)。對(duì)于一般的應(yīng)用，答案沒有理由只應(yīng)獨(dú)一無‘二’。然而更新穎的Java框架（閱讀：Spring + Hibernate）使你獲得了那一個(gè)‘二’，但是你也要做一大堆的配置。那樣，很多方面， 混淆了你的代碼。大量的因素促成我我的演說“擁有一個(gè)有效的默認(rèn)配置/操作”，但是那是不同的故事了。

??? 2，你一向不屑把Ruby on Rails看作是technorati中的后起之秀。你是根本就不想接受還是只是厭惡這種夸夸其談呢？

??? 并不是我真的這樣不屑。Rails在很多重要的方面來說非常優(yōu)秀。事實(shí)上，如果PHP是那要死的飛行意粉怪，并且要給Ruby替代，我想那將是一個(gè)大進(jìn)步。然而，盡管Ruby確實(shí)掃除了過去的錯(cuò)誤，它仍然缺乏Java那么多的功能，但是Ruby為快速開發(fā)提供了一個(gè)引人注目新的開發(fā)模型。你可能反對(duì)，這僅僅是時(shí)間問題，假以時(shí)日，它一定可以的。然而，我對(duì)Ruby/Rails有一些敵意， 是因?yàn)槲乙恍┮恢倍荚谙Ｍ鹙ava能夠擁有的特性，一直長(zhǎng)期希望J2EE能夠擁有簡(jiǎn)單性。

??? 3，那么是什么促使你繼續(xù)留在Java陣營(yíng)，你看中它的什么呢？

??? 按照我日常的工作，在400上沒有必要使用Ruby調(diào)用PCML/RPG程序。同樣，那些大量的java擁有的 “企業(yè)級(jí)”特性很重要，更不用說它是一個(gè)統(tǒng)一的打包和部署的框架。

??? 4，你說“然而，Java像是變成了無所不包的了，它不是‘web的語言’，也不是桌面應(yīng)用的‘一等公民’。”Java是否應(yīng)該放棄一些野心，專注在一個(gè)更小應(yīng)用空間集合里？如果那樣，放棄哪個(gè)？

??? 你也知道，我在我的站點(diǎn)上和一個(gè)紳士有很長(zhǎng)的討論。他指出了Java在J2ME世界的成功，TME/TiVo，置頂盒——或許是下一代DVD的混戰(zhàn)。這些對(duì)于開發(fā)來說都是有效的領(lǐng)域，但是我認(rèn)為如果Java變成了這樣的一個(gè)系統(tǒng)，那將是一個(gè)損失。

??? 使我惱怒的是Java發(fā)明的“applet”，你看看Flash（加上Flex/Laszlo），它的“Cool”（快速的用戶體驗(yàn)）和“強(qiáng)大的”（我免費(fèi)的得到數(shù)據(jù)綁定/SOAP/XML-RPC等等）使applets無地自容。“強(qiáng)大的”缺不需要JRE的事實(shí)立馬扼殺了applet的生存空間，如果有人能以接近數(shù)目的代碼行數(shù)向我展示Laszlo Dashboard demo，我可能已經(jīng)在那個(gè)方面得到了一個(gè)核心發(fā)展。Cool是需要很大的代價(jià)的。

??? 5，Java越來越多的復(fù)雜性，越來越多的競(jìng)爭(zhēng)框架，這是你之前批評(píng)很多次的。我們用JDK 1.2的語義編碼，手工編寫servlet是不是更好呢？

??? 我認(rèn)為的復(fù)雜性是很難管理。例如，如果你從一個(gè)VB背景開始關(guān)注使用Swing，那是非常令人難受的。當(dāng)你需要做一些技巧性的東西，沒有一個(gè)“簡(jiǎn)單”接口可以Cast成更加“高級(jí)”的接口。坦白的說，最近出現(xiàn)的一個(gè)有用的東西就是JAX-P了。在我頭腦中，還有一些東西jre沒有的，但是卻是必須存在的。Swing存在有多久了？然而還沒有東西可以給你像VB5的數(shù)據(jù)綁定表格控制的功能。

??? 我想JDK 1.5的提升是非常顯著的。當(dāng)我談到“降低復(fù)雜性”，我真正指的是A）對(duì)于一件事情， 給予更多標(biāo)準(zhǔn)的途徑來完成，因此如果我真正需要一些不同的特性，我僅僅需要一個(gè)外部的框架。B）設(shè)計(jì)更加友好的API――認(rèn)真的說，看看JavaMail的JavaDoc，看看研究出如何發(fā)送一個(gè)HTML格式的email要花費(fèi)你多長(zhǎng)時(shí)間。C）增加更加通用的功能到核心運(yùn)行環(huán)境，提供一個(gè)可以分別與基于Flash，RIA和桌面領(lǐng)域的Avalon/Sparkle相比擬的風(fēng)格和性能。同樣的，我記得以前天真地從VB/VC++轉(zhuǎn)到Java世界，想道“天哪，本來一直就應(yīng)該是這樣的。”幾年前，我不能說我看到任何增加到Java的東西都是和我有同樣的想法（除了將要來臨的JAX-WS API）。看看Rails，你會(huì)有同樣的感覺。看看Flex你也有同樣的感覺。看看Avalon你也有同樣的感覺。不是我不喜歡Ruby，只是看上去Java不再可以與時(shí)俱進(jìn)讓我很沮喪。

??? Bill Venners：發(fā)行人的觀點(diǎn)

??? Artima是很多Java開發(fā)人員高度關(guān)注的站點(diǎn)。長(zhǎng)久以來它的發(fā)行人Bill Venners是一個(gè)Java著作者和顧問。同時(shí)也是一個(gè)JavaWorld的專欄作家，Inside the Java Virtual Machine的作者。所以，當(dāng)我們注意到Artima上的Ruby內(nèi)容，我們必須找出背后的故事。

??? 1，Artima在很多人眼中一直都是作為一個(gè)Java站點(diǎn)，但是你剛創(chuàng)建一個(gè)一個(gè)新的Ruby版面， Artima當(dāng)今很多的特色文章都是關(guān)于Ruby的，是什么促使了這種改變？

??? 沒有改變。Artima曾經(jīng)是一個(gè)清一色的Java站點(diǎn)，但是幾年前我們擴(kuò)展了更一般開發(fā)焦點(diǎn)，開始涵蓋其他語言。例如，我們開始在“Python Buzz”集成Python Blogs，在“The C++ Source”刊發(fā)C++文章。我們創(chuàng)建了Ruby Code & Style簡(jiǎn)報(bào)來作為Ruby社區(qū)通過高質(zhì)量，編輯的文章分享信息的地方。

??? 2，你是否認(rèn)為你的Ruby報(bào)道是作為一種趨勢(shì)，或者服務(wù)已作出改變的開發(fā)人員？

??? 我們創(chuàng)建Ruby簡(jiǎn)報(bào)僅僅是為了服務(wù)Ruby社區(qū)。我不知道是不是有一個(gè)趨勢(shì)，我也沒有看到很多Java開發(fā)人員轉(zhuǎn)到Ruby.人們并不只是僅僅需要用一種語言編程。我想掌握一種系統(tǒng)語言是有好處的，例如Java或者C++，和一種腳本語言，例如Ruby或者Python，而且能夠用兩者工作。那樣的話你就可以使用你手中最好的工具來工作了。

??? 3，你的最初少數(shù)Ruby文章幾乎沒有涉及Rails.你是否認(rèn)為Rails背后有一個(gè)大的Ruby故事？你還知道有什么東西使用了Ruby？

??? 除了知道Rails在市場(chǎng)上很有賣點(diǎn)，我對(duì)Rails了解的不多。Rails商人一遍又一遍傳遞了這樣的一個(gè)信息，就是Rails能夠助你很快的創(chuàng)建web應(yīng)用。每個(gè)人都很清楚的收到了這個(gè)信息。我認(rèn)為這是一個(gè)非常好營(yíng)銷工作。我也相信這個(gè)信息，但是快速的創(chuàng)建一個(gè)web應(yīng)用不僅僅是人們所關(guān)心的。有時(shí)人們也關(guān)系與數(shù)據(jù)庫的集成，應(yīng)用服務(wù)器的集群，在這種情形，其他工具可能比Rails更有效率。就Ruby而言，我認(rèn)為它是一種適合腳本和創(chuàng)建系統(tǒng)的多用途的編程語言，與Python同種類別。

??? 4，即使在Rails以前，對(duì)比于其他“敏捷”語言，人們都談?wù)摰絉uby獨(dú)特的吸引Java開發(fā)人員。你認(rèn)為Ruby有什么特別之處呢？為什么它對(duì)于Java移民這么好？

??? 我不相信將會(huì)有很多Java移民或者Ruby尤其適合Java程序員。現(xiàn)在大肆宣稱圍繞著Ruby，或許是因?yàn)镽ails的買賣，所以或許你印象中的移民就是來自于那些宣稱的印象。Ruby是一種好的語言，但是Java也是，Python也是。

??? 5，你是否認(rèn)為我們將會(huì)看到很多Java開發(fā)人員開始學(xué)習(xí)Ruby或者轉(zhuǎn)到Ruby，或者我們將看到一個(gè)新一代直接跳過Java而用Ruby代之？

??? Java不會(huì)離我們而去。在Artima，我們選擇了Java作為新的體系架構(gòu)，而不是Ruby，或者Python，就是因?yàn)樗且粋€(gè)成熟的擁有免費(fèi)和商用的大量工具和API的生態(tài)系統(tǒng)。相對(duì)于Java，是的，當(dāng)使用Ruby或者Python編程的時(shí)候是有一些速度的提升，但是有了現(xiàn)代的像IntelliJ，Eclipse和NetBeans的 Java IDE，你可以在Java里走的更快。但是用Ruby編程是很愜意的，同時(shí)，如果有人可以從Ruby中找到他們的職業(yè)生涯，那么請(qǐng)全力以赴去實(shí)現(xiàn)。

??? 結(jié)語

??? 是否Ruby將橫掃Java？不僅僅是虔誠(chéng)的Ruby狂熱者在預(yù)言這個(gè)場(chǎng)景。開發(fā)人員的需要觀點(diǎn)， 就像Venners提出的“手上對(duì)工作最優(yōu)的工具”。 至關(guān)重要的是，開發(fā)人員必須對(duì)正確理解和使用這些工具負(fù)責(zé)。也就不難看出Coopper對(duì)于EJB 1.0的大肆宣稱的記憶和Davidson的預(yù)言“如今很有可能有很多垃圾的Ruby on Rails應(yīng)用在編寫中”的聯(lián)系了。無視技術(shù)，讓市場(chǎng)的浪潮沖走是很危險(xiǎn)的。不僅如此，很多人正在告訴我們使用Ruby會(huì)有相當(dāng)大的效率提升，它確實(shí)是一個(gè)理想的工具，因此我們應(yīng)該給予一定的關(guān)注。

??? 作者感謝Bruce Tate， James Duncan Davidson， Robert Cooper， 和 Bill Venners.感謝占用了他們的時(shí)間與ONJava的讀者分享他們的思想。

??? Chris Adamson是ONJava和Java.net的編輯，專攻Java，Mac Os X和多媒體開發(fā)的亞特蘭大地區(qū)的顧問。

　　版權(quán)聲明：任何獲得Matrix授權(quán)的網(wǎng)站，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必保留以下作者信息和鏈接
　　原文: http://www.onjava.com/pub/a/onjava/2005/11/16/ruby-the-rival.html
　　譯文: http://www.matrix.org.cn/resource/article/44/44288_Ruby+Java.html

　　當(dāng)JAVA程序違反了JAVA的語義規(guī)則時(shí)，JAVA虛擬機(jī)就會(huì)將發(fā)生的錯(cuò)誤表示為一個(gè)異常。違反語義規(guī)則包括2種情況。一種是JAVA類庫內(nèi)置的語義檢查。例如數(shù)組下標(biāo)越界，會(huì)引發(fā)IndexOutOfBoundsException；訪問null的對(duì)象時(shí)會(huì)引發(fā)NullPointerException.另一種情況就是JAVA允許程序員擴(kuò)展這種語義檢查，程序員可以創(chuàng)建自己的異常，并自由選擇在何時(shí)用throw關(guān)鍵字引發(fā)異常。所有的異常都是java.lang.Thowable的子類。

　　2. Java的接口和C++的虛類的相同和不同處。

　　由于Java不支持多繼承，而有可能某個(gè)類或?qū)ο笠褂梅謩e在幾個(gè)類或?qū)ο罄锩娴姆椒ɑ驅(qū)傩裕F(xiàn)有的單繼承機(jī)制就不能滿足要求。與繼承相比，接口有更高的靈活性，因?yàn)榻涌谥袥]有任何實(shí)現(xiàn)代碼。當(dāng)一個(gè)類實(shí)現(xiàn)了接口以后，該類要實(shí)現(xiàn)接口里面所有的方法和屬性，并且接口里面的屬性在默認(rèn)狀態(tài)下面都是public static，所有方法默認(rèn)情況下是public.一個(gè)類可以實(shí)現(xiàn)多個(gè)接口。

　　3. 垃圾回收的優(yōu)點(diǎn)和原理。并考慮2種回收機(jī)制。

　　Java語言中一個(gè)顯著的特點(diǎn)就是引入了垃圾回收機(jī)制，使c++程序員最頭疼的內(nèi)存管理的問題迎刃而解，它使得Java程序員在編寫程序的時(shí)候不再需要考慮內(nèi)存管理。由于有個(gè)垃圾回收機(jī)制，Java中的對(duì)象不再有“作用域”的概念，只有對(duì)象的引用才有“作用域”。垃圾回收可以有效的防止內(nèi)存泄露，有效的使用可以使用的內(nèi)存。垃圾回收器通常是作為一個(gè)單獨(dú)的低級(jí)別的線程運(yùn)行，不可預(yù)知的情況下對(duì)內(nèi)存堆中已經(jīng)死亡的或者長(zhǎng)時(shí)間沒有使用的對(duì)象進(jìn)行清楚和回收，程序員不能實(shí)時(shí)的調(diào)用垃圾回收器對(duì)某個(gè)對(duì)象或所有對(duì)象進(jìn)行垃圾回收。回收機(jī)制有分代復(fù)制垃圾回收和標(biāo)記垃圾回收，增量垃圾回收。

　　4. 請(qǐng)說出你所知道的線程同步的方法。

　　wait（）：使一個(gè)線程處于等待狀態(tài)，并且釋放所持有的對(duì)象的lock.

　　sleep（）：使一個(gè)正在運(yùn)行的線程處于睡眠狀態(tài)，是一個(gè)靜態(tài)方法，調(diào)用此方法要捕捉InterruptedException異常。

　　notify（）：?jiǎn)拘岩粋€(gè)處于等待狀態(tài)的線程，注意的是在調(diào)用此方法的時(shí)候，并不能確切的喚醒某一個(gè)等待狀態(tài)的線程，而是由JVM確定喚醒哪個(gè)線程，而且不是按優(yōu)先級(jí)。

　　Allnotity（）：?jiǎn)拘阉刑幦氲却隣顟B(tài)的線程，注意并不是給所有喚醒線程一個(gè)對(duì)象的鎖，而是讓它們競(jìng)爭(zhēng)。

　　5. 請(qǐng)講一講析構(gòu)函數(shù)和虛函數(shù)的用法和作用。

　　6. Error與Exception有什么區(qū)別？

　　Error表示系統(tǒng)級(jí)的錯(cuò)誤和程序不必處理的異常，

　　Exception表示需要捕捉或者需要程序進(jìn)行處理的異常。

　　7. 在java中一個(gè)類被聲明為final類型，表示了什么意思？

　　表示該類不能被繼承，是頂級(jí)類。

　　8. 描述一下你最常用的編程風(fēng)格。

　　9. heap和stack有什么區(qū)別。

　　棧是一種線形集合，其添加和刪除元素的操作應(yīng)在同一段完成。棧按照后進(jìn)先出的方式進(jìn)行處理。

　　堆是棧的一個(gè)組成元素

　　10. 如果系統(tǒng)要使用超大整數(shù)（超過long長(zhǎng)度范圍），請(qǐng)你設(shè)計(jì)一個(gè)數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)這種超大型數(shù)字以及設(shè)計(jì)一種算法來實(shí)現(xiàn)超大整數(shù)加法運(yùn)算）。

　　public class B{

　　int[] ArrOne = new ArrOne[1000]；

　　String intString=""；

　　public int[] Arr（String s）

　　{

　　intString = s；

　　for（int i=0；i {

　　11. 如果要設(shè)計(jì)一個(gè)圖形系統(tǒng)，請(qǐng)你設(shè)計(jì)基本的圖形元件（Point，Line，Rectangle，Triangle）的簡(jiǎn)單實(shí)現(xiàn)

　　12，談?wù)刦inal， finally， finalize的區(qū)別。

　　final？修飾符（關(guān)鍵字）如果一個(gè)類被聲明為final，意味著它不能再派生出新的子類，不能作為父類被繼承。因此一個(gè)類不能既被聲明為 abstract的，又被聲明為final的。將變量或方法聲明為final，可以保證它們?cè)谑褂弥胁槐桓淖儭１宦暶鳛閒inal的變量必須在聲明時(shí)給定初值，而在以后的引用中只能讀取，不可修改。被聲明為final的方法也同樣只能使用，不能重載。

　　finally？再異常處理時(shí)提供 finally 塊來執(zhí)行任何清除操作。如果拋出一個(gè)異常，那么相匹配的 catch 子句就會(huì)執(zhí)行，然后控制就會(huì)進(jìn)入 finally 塊（如果有的話）。

　　finalize？方法名。Java 技術(shù)允許使用 finalize（） 方法在垃圾收集器將對(duì)象從內(nèi)存中清除出去之前做必要的清理工作。這個(gè)方法是由垃圾收集器在確定這個(gè)對(duì)象沒有被引用時(shí)對(duì)這個(gè)對(duì)象調(diào)用的。它是在 Object 類中定義的，因此所有的類都繼承了它。子類覆蓋 finalize（） 方法以整理系統(tǒng)資源或者執(zhí)行其他清理工作。finalize（） 方法是在垃圾收集器刪除對(duì)象之前對(duì)這個(gè)對(duì)象調(diào)用的。

　　13，Anonymous Inner Class （匿名內(nèi)部類） 是否可以extends（繼承）其它類，是否可以implements（實(shí)現(xiàn)）interface（接口）？

　　匿名的內(nèi)部類是沒有名字的內(nèi)部類。不能extends（繼承） 其它類，但一個(gè)內(nèi)部類可以作為一個(gè)接口，由另一個(gè)內(nèi)部類實(shí)現(xiàn)。

　　14，Static Nested Class 和 Inner Class的不同，說得越多越好（面試題有的很籠統(tǒng)）。

　　Nested Class （一般是C++的說法），Inner Class （一般是JAVA的說法）。Java內(nèi)部類與C++嵌套類最大的不同就在于是否有指向外部的引用上。具體可見http： //www.frontfree.net/articles/services/view.ASP？id=704&page=1

　　注： 靜態(tài)內(nèi)部類（Inner Class）意味著1創(chuàng)建一個(gè)static內(nèi)部類的對(duì)象，不需要一個(gè)外部類對(duì)象，2不能從一個(gè)static內(nèi)部類的一個(gè)對(duì)象訪問一個(gè)外部類對(duì)象

　　第四，&和&&的區(qū)別。

　　&是位運(yùn)算符。&&是布爾邏輯運(yùn)算符。

　　15，HashMap和Hashtable的區(qū)別。

　　都屬于Map接口的類，實(shí)現(xiàn)了將惟一鍵映射到特定的值上。

　　HashMap 類沒有分類或者排序。它允許一個(gè) null 鍵和多個(gè) null 值。

　　Hashtable 類似于 HashMap，但是不允許 null 鍵和 null 值。它也比 HashMap 慢，因?yàn)樗峭降摹?/p>

　　16，Collection 和 Collections的區(qū)別。

　　Collections是個(gè)java.util下的類，它包含有各種有關(guān)集合操作的靜態(tài)方法。

　　Collection是個(gè)java.util下的接口，它是各種集合結(jié)構(gòu)的父接口。

　　17，什么時(shí)候用assert.

　　斷言是一個(gè)包含布爾表達(dá)式的語句，在執(zhí)行這個(gè)語句時(shí)假定該表達(dá)式為 true.如果表達(dá)式計(jì)算為 false，那么系統(tǒng)會(huì)報(bào)告一個(gè) Assertionerror.它用于調(diào)試目的：

　　assert（a > 0）； // throws an Assertionerror if a <= 0

　　斷言可以有兩種形式：

　　assert Expression1 ；

　　assert Expression1 ： Expression2 ；

　　Expression1 應(yīng)該總是產(chǎn)生一個(gè)布爾值。

　　Expression2 可以是得出一個(gè)值的任意表達(dá)式。這個(gè)值用于生成顯示更多調(diào)試信息的 String 消息。

　　斷言在默認(rèn)情況下是禁用的。要在編譯時(shí)啟用斷言，需要使用 source 1.4 標(biāo)記：

　　javac -source 1.4 Test.java

　　要在運(yùn)行時(shí)啟用斷言，可使用 -enableassertions 或者 -ea 標(biāo)記。

　　要在運(yùn)行時(shí)選擇禁用斷言，可使用 -da 或者 -disableassertions 標(biāo)記。

　　要系統(tǒng)類中啟用斷言，可使用 -esa 或者 -dsa 標(biāo)記。還可以在包的基礎(chǔ)上啟用或者禁用斷言。

　　可以在預(yù)計(jì)正常情況下不會(huì)到達(dá)的任何位置上放置斷言。斷言可以用于驗(yàn)證傳遞給私有方法的參數(shù)。不過，斷言不應(yīng)該用于驗(yàn)證傳遞給公有方法的參數(shù)，因?yàn)椴还苁欠駟⒂昧藬嘌裕蟹椒ǘ急仨殭z查其參數(shù)。不過，既可以在公有方法中，也可以在非公有方法中利用斷言測(cè)試后置條件。另外，斷言不應(yīng)該以任何方式改變程序的狀態(tài)。

　　18，GC是什么？ 為什么要有GC？ （基礎(chǔ)）。

　　GC是垃圾收集器。Java 程序員不用擔(dān)心內(nèi)存管理，因?yàn)槔占鲿?huì)自動(dòng)進(jìn)行管理。要請(qǐng)求垃圾收集，可以調(diào)用下面的方法之一：

　　System.gc（）

　　Runtime.getRuntime（）。gc（）

　　19，String s = new String（"xyz"）；創(chuàng)建了幾個(gè)String Object？

　　兩個(gè)對(duì)象，一個(gè)是“xyx”，一個(gè)是指向“xyx”的引用對(duì)象s.

　　20，Math.round（11.5）等於多少？ Math.round（-11.5）等於多少？

　　Math.round（11.5）返回（long）12，Math.round（-11.5）返回（long）-11；

　　21，short s1 = 1； s1 = s1 + 1；有什么錯(cuò)？ short s1 = 1； s1 += 1；有什么錯(cuò)？

　　short s1 = 1； s1 = s1 + 1；有錯(cuò)，s1是short型，s1+1是int型，不能顯式轉(zhuǎn)化為short型。可修改為s1 =（short）（s1 + 1） .short s1 = 1； s1 += 1正確。

　　22，sleep（） 和 wait（） 有什么區(qū)別？ 搞線程的最愛

　　sleep（）方法是使線程停止一段時(shí)間的方法。在sleep 時(shí)間間隔期滿后，線程不一定立即恢復(fù)執(zhí)行。這是因?yàn)樵谀莻€(gè)時(shí)刻，其它線程可能正在運(yùn)行而且沒有被調(diào)度為放棄執(zhí)行，除非（a）“醒來”的線程具有更高的優(yōu)先級(jí) （b）正在運(yùn)行的線程因?yàn)槠渌蚨枞?/p>

　　wait（）是線程交互時(shí)，如果線程對(duì)一個(gè)同步對(duì)象x 發(fā)出一個(gè)wait（）調(diào)用，該線程會(huì)暫停執(zhí)行，被調(diào)對(duì)象進(jìn)入等待狀態(tài)，直到被喚醒或等待時(shí)間到。

　　23，Java有沒有g(shù)oto？

　　Goto？java中的保留字，現(xiàn)在沒有在java中使用。

　　24，數(shù)組有沒有l(wèi)ength（）這個(gè)方法？ String有沒有l(wèi)ength（）這個(gè)方法？

　　數(shù)組沒有l(wèi)ength（）這個(gè)方法，有l(wèi)ength的屬性。

　　String有有l(wèi)ength（）這個(gè)方法。

　　25，Overload和Override的區(qū)別。Overloaded的方法是否可以改變返回值的類型？

　　方法的重寫Overriding和重載Overloading是Java多態(tài)性的不同表現(xiàn)。重寫Overriding是父類與子類之間多態(tài)性的一種表現(xiàn)，重載Overloading是一個(gè)類中多態(tài)性的一種表現(xiàn)。如果在子類中定義某方法與其父類有相同的名稱和參數(shù)，我們說該方法被重寫 （Overriding）。子類的對(duì)象使用這個(gè)方法時(shí)，將調(diào)用子類中的定義，對(duì)它而言，父類中的定義如同被“屏蔽”了。如果在一個(gè)類中定義了多個(gè)同名的方法，它們或有不同的參數(shù)個(gè)數(shù)或有不同的參數(shù)類型，則稱為方法的重載（Overloading）。Overloaded的方法是可以改變返回值的類型。

　　26，Set里的元素是不能重復(fù)的，那么用什么方法來區(qū)分重復(fù)與否呢？ 是用==還是equals（）？ 它們有何區(qū)別？

　　Set里的元素是不能重復(fù)的，那么用iterator（）方法來區(qū)分重復(fù)與否。equals（）是判讀兩個(gè)Set是否相等。

　　equals（）和==方法決定引用值是否指向同一對(duì)象equals（）在類中被覆蓋，為的是當(dāng)兩個(gè)分離的對(duì)象的內(nèi)容和類型相配的話，返回真值。

第二，Anonymous Inner Class (匿名內(nèi)部類) 是否可以extends(繼承)其它類，是否可以implements(實(shí)現(xiàn))interface(接口)?
匿名的內(nèi)部類是沒有名字的內(nèi)部類。不能extends(繼承) 其它類，但一個(gè)內(nèi)部類可以作為一個(gè)接口，由另一個(gè)內(nèi)部類實(shí)現(xiàn)。

第三，Static Nested Class 和 Inner Class的不同，說得越多越好(面試題有的很籠統(tǒng))。
Nested Class （一般是C++的說法），Inner Class (一般是JAVA的說法)。Java內(nèi)部類與C++嵌套類最大的不同就在于是否有指向外部的引用上。具體可見http: //www.frontfree.net/articles/services/view.asp?id=704&page=1
注： 靜態(tài)內(nèi)部類（Inner Class）意味著1創(chuàng)建一個(gè)static內(nèi)部類的對(duì)象，不需要一個(gè)外部類對(duì)象，2不能從一個(gè)static內(nèi)部類的一個(gè)對(duì)象訪問一個(gè)外部類對(duì)象

第四，&和&&的區(qū)別。
&是位運(yùn)算符。&&是布爾邏輯運(yùn)算符。

第五，HashMap和Hashtable的區(qū)別。
都屬于Map接口的類，實(shí)現(xiàn)了將惟一鍵映射到特定的值上。
HashMap 類沒有分類或者排序。它允許一個(gè) null 鍵和多個(gè) null 值。
Hashtable 類似于 HashMap，但是不允許 null 鍵和 null 值。它也比 HashMap 慢，因?yàn)樗峭降摹?

第六，Collection 和 Collections的區(qū)別。
Collections是個(gè)java.util下的類，它包含有各種有關(guān)集合操作的靜態(tài)方法。
Collection是個(gè)java.util下的接口，它是各種集合結(jié)構(gòu)的父接口。

第七，什么時(shí)候用assert。
斷言是一個(gè)包含布爾表達(dá)式的語句，在執(zhí)行這個(gè)語句時(shí)假定該表達(dá)式為 true。如果表達(dá)式計(jì)算為 false，那么系統(tǒng)會(huì)報(bào)告一個(gè) AssertionError。它用于調(diào)試目的：
assert(a > 0); // throws an AssertionError if a <= 0
斷言可以有兩種形式：
assert Expression1 ;
assert Expression1 : Expression2 ;
Expression1 應(yīng)該總是產(chǎn)生一個(gè)布爾值。
Expression2 可以是得出一個(gè)值的任意表達(dá)式。這個(gè)值用于生成顯示更多調(diào)試信息的 String 消息。
斷言在默認(rèn)情況下是禁用的。要在編譯時(shí)啟用斷言，需要使用 source 1.4 標(biāo)記：
javac -source 1.4 Test.java
要在運(yùn)行時(shí)啟用斷言，可使用 -enableassertions 或者 -ea 標(biāo)記。
要在運(yùn)行時(shí)選擇禁用斷言，可使用 -da 或者 -disableassertions 標(biāo)記。
要系統(tǒng)類中啟用斷言，可使用 -esa 或者 -dsa 標(biāo)記。還可以在包的基礎(chǔ)上啟用或者禁用斷言。
可以在預(yù)計(jì)正常情況下不會(huì)到達(dá)的任何位置上放置斷言。斷言可以用于驗(yàn)證傳遞給私有方法的參數(shù)。不過，斷言不應(yīng)該用于驗(yàn)證傳遞給公有方法的參數(shù)，因?yàn)椴还苁欠駟⒂昧藬嘌裕蟹椒ǘ急仨殭z查其參數(shù)。不過，既可以在公有方法中，也可以在非公有方法中利用斷言測(cè)試后置條件。另外，斷言不應(yīng)該以任何方式改變程序的狀態(tài)。

第八，GC是什么? 為什么要有GC? (基礎(chǔ))。
GC是垃圾收集器。Java 程序員不用擔(dān)心內(nèi)存管理，因?yàn)槔占鲿?huì)自動(dòng)進(jìn)行管理。要請(qǐng)求垃圾收集，可以調(diào)用下面的方法之一：
System.gc()
Runtime.getRuntime().gc()

第九，String s = new String("xyz");創(chuàng)建了幾個(gè)String Object?
兩個(gè)對(duì)象，一個(gè)是“xyx”,一個(gè)是指向“xyx”的引用對(duì)象s。

第十，Math.round(11.5)等於多少? Math.round(-11.5)等於多少?
Math.round(11.5)返回（long）12，Math.round(-11.5)返回（long）-11;
第二十一，abstract的method是否可同時(shí)是static,是否可同時(shí)是native，是否可同時(shí)是synchronized?
都不能

第二十二，接口是否可繼承接口? 抽象類是否可實(shí)現(xiàn)(implements)接口? 抽象類是否可繼承實(shí)體類(concrete class)?
接口可以繼承接口。抽象類可以實(shí)現(xiàn)(implements)接口，抽象類是否可繼承實(shí)體類，但前提是實(shí)體類必須有明確的構(gòu)造函數(shù)。

第二十三，啟動(dòng)一個(gè)線程是用run()還是start()?
啟動(dòng)一個(gè)線程是調(diào)用start()方法，使線程所代表的虛擬處理機(jī)處于可運(yùn)行狀態(tài)，這意味著它可以由JVM調(diào)度并執(zhí)行。這并不意味著線程就會(huì)立即運(yùn)行。run()方法可以產(chǎn)生必須退出的標(biāo)志來停止一個(gè)線程。

第二十四，構(gòu)造器Constructor是否可被override?
構(gòu)造器Constructor不能被繼承，因此不能重寫Overriding，但可以被重載Overloading。

第二十五，是否可以繼承String類?
String類是final類故不可以繼承。

第二十六，當(dāng)一個(gè)線程進(jìn)入一個(gè)對(duì)象的一個(gè)synchronized方法后，其它線程是否可進(jìn)入此對(duì)象的其它方法?
不能，一個(gè)對(duì)象的一個(gè)synchronized方法只能由一個(gè)線程訪問。

第二十七，try {}里有一個(gè)return語句，那么緊跟在這個(gè)try后的finally {}里的code會(huì)不會(huì)被執(zhí)行，什么時(shí)候被執(zhí)行，在return前還是后?
會(huì)執(zhí)行，在return前執(zhí)行。

第二十八，編程題: 用最有效率的方法算出2乘以8等於幾?
有C背景的程序員特別喜歡問這種問題。

2 << 3

第二十九，兩個(gè)對(duì)象值相同(x.equals(y) == true)，但卻可有不同的hash code，這句話對(duì)不對(duì)?
不對(duì)，有相同的hash code。

第三十，當(dāng)一個(gè)對(duì)象被當(dāng)作參數(shù)傳遞到一個(gè)方法后，此方法可改變這個(gè)對(duì)象的屬性，并可返回變化后的結(jié)果，那么這里到底是值傳遞還是引用傳遞?
是值傳遞。Java 編程語言只由值傳遞參數(shù)。當(dāng)一個(gè)對(duì)象實(shí)例作為一個(gè)參數(shù)被傳遞到方法中時(shí)，參數(shù)的值就是對(duì)該對(duì)象的引用。對(duì)象的內(nèi)容可以在被調(diào)用的方法中改變，但對(duì)象的引用是永遠(yuǎn)不會(huì)改變的。

第三十一，swtich是否能作用在byte上，是否能作用在long上，是否能作用在String上?
switch（expr1）中，expr1是一個(gè)整數(shù)表達(dá)式。因此傳遞給 switch 和 case 語句的參數(shù)應(yīng)該是 int、 short、 char 或者 byte。long,string 都不能作用于swtich。

第三十二，編程題: 寫一個(gè)Singleton出來。
Singleton模式主要作用是保證在Java應(yīng)用程序中，一個(gè)類Class只有一個(gè)實(shí)例存在。
一般Singleton模式通常有幾種種形式:
第一種形式: 定義一個(gè)類，它的構(gòu)造函數(shù)為private的，它有一個(gè)static的private的該類變量，在類初始化時(shí)實(shí)例話，通過一個(gè)public的getInstance方法獲取對(duì)它的引用,繼而調(diào)用其中的方法。
public class Singleton {
　　private Singleton(){}
　　//在自己內(nèi)部定義自己一個(gè)實(shí)例，是不是很奇怪？
　　//注意這是private 只供內(nèi)部調(diào)用
　　private static Singleton instance = new Singleton();
　　//這里提供了一個(gè)供外部訪問本class的靜態(tài)方法，可以直接訪問　　
　　public static Singleton getInstance() {
　　　　return instance; 　　
　　 }
}
第二種形式:
public class Singleton {
　　private static Singleton instance = null;
　　public static synchronized Singleton getInstance() {
　　//這個(gè)方法比上面有所改進(jìn)，不用每次都進(jìn)行生成對(duì)象，只是第一次　　　 　
　　//使用時(shí)生成實(shí)例，提高了效率！
　　if (instance==null)
　　　　instance＝new Singleton();
return instance; 　　}
}