sun和java的簡單介紹

本文目錄一覽：

• 1、Android java虛擬機和sun java虛擬機區別
• 2、sun公司對java編程語言的解釋是什麼?
• 3、java不是開源的嗎，那麼sun公司怎麼通過java賺錢了
• 4、SUN JAVA認證有哪些
• 5、sunjava是什麼品牌

Android java虛擬機和sun java虛擬機區別

(1) Dalvik VM和JVM 的第一個區別是 Dalvik VM是基於寄存器的架構（reg based），而JVM是棧機（stack based）。reg based VM的好處是可以做到更好的提前優化（ahead-of-time optimization）。 另外reg based的VM執行起來更快，但是代價是更大的代碼長度。

(2) 另外一個區別是Dalvik可以允許多個instance 運行，也就是說每一個Android 的App是獨立跑在一個VM中.這樣做的好處是一個App crash只會影響到自身的VM，不會影響到其他。 Dalvik的設計是每一個Dalvik的VM都是Linux下面的一個進程。那麼這就需要高效的IPC。另外每一個VM是單獨運行的好處還有可以動態active/deactive自己的VM而不會影響到其他VM

(3) 接下來就是關於版權之類爭論。（可以參看下面文章）

既然reg based VM有那麼多好處，為什麼之前設計JAVA的人沒有採用reg based而是採用stack based的呢？ 原來stack based的VM也有其優點，就是它不對host平台的reg數量做假設，有利於移植到不同的平台。而Dalvik則不關心這些，因為它本來就是為ARM這樣的多reg平台設計的。另外Dalvik被移植到x86也說明，即使是x86這種reg很少的平台，reg based的VM也是沒有問題的。

下面着重說下DVM的優勢：（部分文字我加黑以突出）

1、在編譯時提前優化代碼而不是等到運行時

2、 虛擬機很小，使用的空間也小；被設計來滿足可高效運行多種虛擬機實例。

3、常量池已被修改為只使用32位的索引，以 簡化解釋器

JVM 的位元組碼主要是零地址形式的，概念上說JVM是基於棧的架構。Google Android平台上的應用程序的主要開發語言是Java，通過其中的Dalvik VM來運行Java程序。為了能正確實現語義，Dalvik VM的許多設計都考慮到與JVM的兼容性；但它卻採用了基於寄存器的架構，其位元組碼主要是二地址/三地址的混合形式。

基於棧與基於寄存器的 架構，誰更快？現在實際的處理器，大多都是基於寄存器的架構，從側面反映出基於寄存器比基於棧的架構更與實際的處理器接近。但對於VM來說，源架構的求值 棧或者寄存器都可能是用實際機器的內存來模擬的，所以性能特性與實際硬件又有不同。一般認為基於寄存器架構的Dalvik VM比基於棧架構JVM執行效率更高，原因是：雖然零地址指令更緊湊，但完成操作需要更多的load/store指令，也意味着更多的指令分派 （instruction dispatch）次數與內存訪問次數；訪問內存是執行速度的一個重要瓶頸，二地址或三地址指令雖然每條指令占的空間較多，但總體來說可以用更少的指令完 成操作，指令分派與內存訪問次數都較少。

我們從下面的截圖可以明了的看到與同一段Java代碼對應的Java bytecode 與Dalvid bytecode的比較：

網上一些文章在討論 Dalvik 時，大都簡單提及 Dalvik 執行速度比 JVM 快，但移植性稍差。這裡 我們延伸探討一下。在一個解釋器上執行 VM 指令，包含三個步驟，指令分派、訪問操作數和執 行計算。 指令分派（Instructions dispatch）負責從內存中讀取 VM 指令，然後跳轉到相應的解釋器代碼 指令分派 中。上面提到過，完成同樣的事情，基於棧的虛擬機需要更多的指令，意味着更多的指令分派和 內存訪問次數，這是 JVM 的執行性能不如 Dalvik VM 的原因之一。

訪問操作數 訪問操作數（Operands access）是指讀取和寫回源操作數和目的操作數。Dalvik VM 通過虛擬 操作數 寄存器來訪問操作數， 由於具有相近的血緣， Dalvik 的虛擬寄存器在映射到物理寄存器方面具有 更充分的優勢， 這也是 Dalvik VM 性能較佳的一個原因。 JVM 的操作數通過操作數棧來訪問， 而 因為指令中沒有使用任何通用寄存器，在虛擬機的實現中可以比較自由的分配實際機器的寄存 器，因而可移植性高。作為一個優化，操作數棧也可以由編譯器映射到物理寄存器上，減少數據 移動的開銷。 指令執行（Instructions compute）這個似乎沒什麼可解釋的，老老實實執行就行。 指令執行

一個應用中會定義很多類， 編譯完成後即會有很多相應 的CLASS文件，CLASS文件 間會有不少冗餘的信息。

dex位元組碼和標準Java的位元組碼（Class）在結構上的一個區別是dex位元組碼將多個文件整合成一個，這樣，除了減少整體的文件尺寸，I/O操作，也提高了類的查找速度。

原來每個類文件中的常量池現在由DEX文件中一個常量池來管理。

DEX文件可以進行進一步優化。優化主要是針對以下幾個方面：

1、調整所有字段的位元組序（LITTLE_ENDIAN）和對齊結構中的沒一個域

2、驗證DEX文件中的所有類

3、對一些特定的類進行優化，對方法里的操作碼進行優化

優化 優化後的文件大小會有所增加，應該是原DEX文件的1-4倍。 odex是為了在運行過程中進一步提高性能，對dex文件的進一步優化 。

每一個Android應用都運行在一個Dalvik虛擬機實例里，而每一個虛擬機實例都是一個獨立的進程空間。每個進程之間可以通信（IPC，Binder機制實現）。虛擬機的線程機制，內存分配和管理，Mutex等等都是依賴底層操作系統而實現的。

不同的應用在不同的進程空間里運行，當一個虛擬機關閉或意外中止時不會對其它虛擬機造成影響，可以最大程度的保護應用的安全和獨立運行。

Zygote是虛擬機實例的孵化器。AndroidRuntime.cpp中ZygoteInit.main()的執行會完成一個分裂，分裂出來的子進程繼續初始化Java層的架構，這個分裂出來的進程就是system_server。每當系統要求執行一個Android應用程序，Zygote就會FORK出一個子進程來執行該應用程序。這樣做的好處顯而易見：Zygote進程是在系統啟動時產生的，它會完成虛擬機的初始化，庫的加載，預置類庫的加載和初始化等等操作，而在系統需要一個新的虛擬機實例時，Zygote通過複製自身，最快速的提供個系統。另外，對於一些只讀的系統庫，所有虛擬機實例都和Zygote共享一塊內存區域，大大節省了內存開銷。

JVM其核心目的，是為了構建一個真正跨OS平台，跨指令集的程序運行環境（VM）。DVM的目的是為了將android OS的本地資源和環境，以一種統一的界面提供給應用程序開發。嚴格來說，DVM不是真正的VM，它只是開發的時候提供了VM的環境，並不是在運行的時候提供真正的VM容器。這也是為什麼JVM必須設計成stack-based的原因。

JVM：所有的jar程序，其運行環境完全是由JVM來提供，包括運行時，各類資源的調度，而JVM的架構，其設計為一個JVM裏面可以運行多個java程序，JVM就像一個真正的「機器」，可以跑着多個程序。如果去看看一些企業級的JVM（例如tom cat，WAS），從OS的進程管理中，一般你只能看見一個JVM的進程（當然，你也可以起多個JVM，但JVM架構就是OS-JVM-APP的3層運行時模式），而看不見JVM裏面運行的程序，而一個JVM里，可以跑多個java app。簡單得說，JVM完全屏蔽了應用程序和OS之間的聯繫，而改用JVM充當了中間層，這也是一個真正跨平台運行時VM必須要做到的。只要是相同的JDK，JVM為所有在其中運行的程序，提供了完全一致的運行環境，而不論你是什麼樣的底層OS和硬件條件。因此這也是我在其他一篇答案中提到，JVM的特點是取底層OS和硬件環境的交集，從而保障這種一致性。而所有應用程序和底層資源的互動，一定是依賴JVM的傳遞和轉換來實現。JVM真正實現了一個OS對應用程序運行時管理的所有功能。從開發環境角度和運行時角度，都是完全一致的真正VM

DVM：而DVM的特點在於使用了Zygote，Zygote有幾個非常有意思的特點。

一是Zygote採用預加載，由其首先判定安裝的APK的需要以及相互依存樹，以及OS及硬件環境的特點，在每次啟動的時候進行預加載（現在你明白為什麼android的app在應用管理里你能輕易查到它都調用了那些關鍵性的本地資源的原因了吧？），這就意味着，你安裝的應用越多，Zygote的加載就越慢，一般來說你的手機啟動就會越慢。另外來說，在不同的硬件環境里（例如有無GPS芯片）Zygote初始化的實例是不同的。也就是說，zygote並不提供一個統一的運行環境，具有更好的彈性，這種機制意味着DVM可以取底層資源的合集來提供上層應用使用，差別只是在程序安裝或者啟動的過程中，DVM可以提示程序需求資源，本地環境可能未能滿足而導致無法運行。DVM的Zygote並不是提供一個運行時容器，它提供的只是一個用於共享的進程，所有的應用程序運行，都是獨立的，OS級別的進程，直接受到OS層面的資源控制以及調度的影響，只是他們共享Zygote說預加載的類而已。這也就是我為什麼說，DVM就像是給每個應用程序在底層加了個套子，而不是提供了一個真正的運行時的VM。也就是說，DVM在開發環境中說提供的VM平台，和運行時的環境是很有可能不一致的。開發環境中提供的VM平台，是一個各種運行時可能環境的合集。

從這點上來說，一般我們認為，JVM中的JAVA程序的崩潰，最多導致JVM的崩潰，而不會導致OS崩潰，但是apk的崩潰，可以直接導致OS崩潰，android手機會因為應用程序死機，大家應該是很常見了。但是大家一般是不會看到java程序導致死機吧？因為運行時中間隔着一個JVM。（當然，其實還是有些小門道可以用java程序讓OS崩潰，因為這個，我和某些JAVA大拿打賭贏過飯局，呵呵，不過這是其他話題，不在這裡展開了）

除此之外，在JVM的機制中，不同的程序，打包以後，他們都是在運行層級真正獨立的程序（指程序應用他們相互之間的關係，而不是和JVM的關係），即便他們在包里使用了同樣的類，運行時都是單獨加載，單獨運行的（及加載多遍）。

DVM這種預加載-共享的機制，使得不同應用之間，在運行時，是共享相同的類的，一般來說，在系統資源消耗方面，擁有更高的效率。

最後，補充一點，byte code並不意味着就是解釋執行，也能是加載編譯，安裝編譯，預編譯等等。實際上，不同的byte code的程序，不同的技術，不同的具體語言，其真正執行的情況是挺複雜，難以一概而論的，好多都是混合技術的案例，從我對odex的技術來看，就是個典型案例。

sun公司對java編程語言的解釋是什麼?

Sun

公司對

Java

編程語言的解釋是:Java

編程語言是個簡單、面向對象、分佈式、解釋性、健壯、安全與系統無關、可移植、高性能、多線程和靜態的語言。

java不是開源的嗎，那麼sun公司怎麼通過java賺錢了

實際上，Sun在Java上的收益確實不大，遠遠比不過壟斷Java應用服務器技術的IBM和BEA公司，似乎有替別人做嫁衣之嫌。對此，Sun董事長、總裁兼首席執行官Scott McNealy是這樣解釋的:「Sun並沒有用Java賺錢，這就像使用英語不用上稅一樣，Sun並不通過Java本身來盈利，而是把Java應用到了業務中。」原來是放長線釣大魚！

賣硬件和操作系統，他推出服務器和Solaris操作系統。

賣Java配套軟件，比如Sun ONE Studio Enterprise Edition要錢，而且很貴。

提供服務。比如Sun ONE Studio Standard Edition不要錢，但是技術支持要錢。Sun One Application server Identy Server 好多好多，好貴好貴。

SUN JAVA認證有哪些

sun公司推出的java認證包括scjp，scjd，scwcd，scea等等很多認證

其中scjp（java程序員）是最基礎的認證，考其他級別的java認證都需要先考過scjp認證。

scwcd（web組件開發員）和scjd（java開發員）屬於高於scjp一個等級的認證。

scea（企業級架構師）是java認證的最高等級也就是第三級認證。

SCJP好像要七八百，其他的應該也差不多，150美金左右

考的內容就不怎麼深的，不過都是英文，外語菜的人就不要報考了啦！

sunjava是什麼品牌

雅伯蘭（ABL）SUN夏日香水，EDP濃度，產地中國廣州，發源地是法國，50毫升市場價299元RMB，清新花香調

前味：風信子、白麝香，中味：粉紅胡椒、茉莉、香根草、柑橘，後味：鳶尾花、琥珀、廣藿香