查看容器的編譯信息

① Docker常用命令，值得收藏

使用指定的鏡像來運行容器，並可選地在容器中運行指定的命令。

分離模式 ：通過 -d 選項指定；容器會在任務（進程）結束時退出。
前台模式 ：可以將控制台連接到容器中進程的標准輸入、輸出、錯誤；通過 -t 選項可以為其分配一個偽終端；通過 -i 選項可以保持標准輸入處於打開狀態。

--rm 選項能夠在容器退出時自動刪除容器。

羅列容器。

-a 選項可以列出所有的容器。

查看容器的詳細信息。

查看容器中運行的進程。

持續輸出容器的資源使用情況。

查看容器的埠映射。

查看容器的日誌（標准輸出、錯誤的內容）。

-f 選項可以持續輸出容器的日誌。

將本地終端的標准輸入、輸出、錯誤連接到容器。

在運行的容器中執行指定的命令。

使用 freezer cgroup 掛起容器中的所有進程（進程對掛起操作是無感知的）。

恢復容器中掛起的進程。

停止容器，終止容器中的進程：首先發送 SIGTERM 信號給容器中的進程，一段時間之後發送 SIGKILL 信號。

啟動停止的容器（還是運行之前給定的命令）。

刪除指定的容器。

--force 選項可以強制性刪除運行的容器。

在容器和主機之間拷貝文件、目錄。

將容器的文件系統（不包括卷的內容）導出為 tar 文件，後續可通過 docker import 來載入鏡像。

查看所有的頂層鏡像。

-a 選項可以查看所有的鏡像。

搜索 docker hub。

拉取鏡像。

基於源鏡像創建一個包含 tag 的鏡像。

推送鏡像。

從 tar 文件中載入鏡像。

保存鏡像為 tar 文件，後續可通過 docker load 來載入。

可通過 -o 選項將鏡像保存至指定的文件，默認輸出到標准輸出。

從標准輸入或 tar 文件中載入鏡像。

-i 選項指定從 tar 文件中載入鏡像。

刪除本地鏡像。如果 IMAGE 包含了 tag，且該鏡像具有多個 tags，則此命令只是移除該 tag，而不會刪除鏡像。

-f 選項可強制刪除運行容器所用的鏡像。

② docker的容器常規操作

解釋：創建一個容器，但容器處於停止狀態

解釋：啟動容器

解釋：
-t : 讓Docker分配一個偽終端並綁定到容器的標准輸入上
-i: 讓容器的標准輸入保持打開
-d: 讓Docker容器在後台以守護態運行

解釋：
-details:列印詳細信息
-f,-follow:保持持續輸出
-since string:輸出從某個時間開始的日誌
-tail string:輸出最近的若干日誌
-t,-timestamps:輸出時間戳信息
-until string:輸出某個時間之前的日誌

解釋：暫停容器，暫停後，容器處於paused狀態

解釋：將paused狀態的容器恢復至運行狀態

解釋： 終止一個運行狀態的容器，但是這個終止不是立即執行的。該命令會先向容器發送一個SIGTERM信號，等待一段超時時間（默認為10s）後,再發送SIGKILL信號終止容器，而終止容器的關鍵就在於SIGKILL信號。

解釋： 終止一個運行狀態的容器，但是這個終止是立即執行的。該命令直接發送SIGKILL信號強行終止容器。

解釋： 重啟容器

解釋：進入容器。使用這個命令有時候並不方便，當多個窗口同時attach到同一個容器的時候，所有窗口都會同步顯示；當某個窗口因命令阻塞時，其他窗口也無法執行操作；默認使用CTRL+q或者CTRL+p退出容器

解釋：
-d,--detach:在容器中後台執行命令
--detach-keys="":指定將容器切回後台的案件
-e,--env=[]:指定環境變數列表
-i,--interactive=true|false:打開標准輸入接收用戶輸入命令，默認值為false
--privileged=true|false:是否給執行命令以高許可權，默認值為false
-t,--try=true|false:分配偽終端，默認值為false
-u，--user=""：執行命令的用戶名或ID

解釋：
刪除處於退出或者終止狀態的容器
-f,--force=false:是否強行終止並刪除一個處於運行狀態的容器
-l,--link=false:刪除容器的鏈接，但保留容器
-v,--volumns=false:刪除容器掛載的數據卷

解釋：導出容器。導出一個已經創建的容器到文件，不管此時這個容器是否處於運行狀態。在這里如果把export換成save，再把af18換成鏡像名稱：tag，就是導出鏡像的命令了。但是這兩個命令的區別在於：docker export命令丟棄了原容器的歷史信息及元數據,而docker save命令會保留原文件的歷史信息。

解釋：將導出的文件變成鏡像。當然，這個也可以用docker load命令來執行。

解釋：查看容器具體信息，比如：容器ID,創建時間，路徑，狀態，鏡像，配置等

解釋： 查看容器內進程信息

解釋：查看容器的內存、CPU、存儲、網路等使用情況
-a,-all:輸出所有容器統計信息
-format string: 格式化輸出信息
-no-stream:不持續輸出，默認會自動更新持續實時結果
-no-trunc:不截斷輸出信息

解釋：第一行命令為將test容器的temp文件夾復制到主機的data文件夾下
第二行的命令為將主機的data文件夾復制到test容器的tmp文件夾下

解釋：查看容器內的數據修改

解釋：查看test容器的埠映射情況

解釋：修改容器的一些運行時配置。主要是一些資源限制配額。

③ 很多應用容器都是默認後台運行的，怎麼查看它們的輸出和日誌信息

使用docker logs，後面跟容器的名稱或者ID信息，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。 如果我的回答能夠對您有幫助的話，求給大大的贊。

④ Docker檢查運行中的容器的詳細信息

查看容器中詳細信息，命令很簡單，dcoker inspect id

首先用docker ps查看所有啟動的鏡像，

[root@bogon ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
44ab452b47fe docker.io/ubuntu:latest "/bin/bash" About a minute ago Up About a minute prickly_blackwell
[root@bogon ~]#

可以看到id是 44ab。。。。

利用命令查看容器的詳細信息
[root@bogon ~]# docker inspect 44ab452b4
[
{
"Id": "",
"Created": "2016-01-12T13:46:16.365773903Z",
"Path": "/bin/bash",
"Args": [],
"State": {

輸出太多了 我只截取了一部分。

⑤ Docker：容器管理（啟動參數，查看容器和日誌，進入和修改容器）

摘要： Docker

容器是一個精簡版的操作系統，一般一個容器只運行一個應用，容器通過鏡像創建，使用 docker run 命令創建，容器起到了 隔離 作用，容器和容器之間獨享空間和網路等

容器的基本操作包括創建（啟動），停止，重啟，查看，檢查等，容器通過鏡像創建，使用 docker run 命令創建，需要指定run參數，鏡像名，容器執行命令，語句格式如下

在實際使用中啟動一個鏡像，例如

-e 設置環境變數，格式是 -e k1=v1 -e k2=v2 ，使得在docker鏡像中的程序能夠直接訪問到環境變數，同時可以作為配置參數放在docker run啟動鏡像的時候設置，而不是寫死在dockerfile在build的過程中，-e和dockerfile中的 ENV 變數作用相同，當變數重名時-e替換ENV，下面測試一些-e參數，在Dockerfile指定環境變數

直接構建成容器

開啟一個終端啟動容器內部，列印指定的環境變數a

此時在run指令中增加-e設置環境變數，可見-e替換了Dockerfile中指定的環境變數

因為一個鏡像可以啟動多個容器，所以可以通過設置不同-e達到設置不同配置參數的目的，比如下一個例子在Dockerfile中設置和將環境變數寫入yaml文件再供Python調用，執行的內容為列印yaml配置文件的參數內容，比如下面這個例子先看下目錄結構

其中config.yml是一個空配置文件，在run.sh中先使用echo寫入追加配置參數到config.yml在執行Python腳本

Dockerfile中啟動run.sh腳本作為容器執行命令

在啟動容器時，使用-e指定環境變數，在run.sh中echo將環境變數拿到和寫入配置文件，測試多次以不同的配置參數啟動容器如下

-v 設置掛載運行，將宿主機當前目錄下的文件掛載到容器中/home目錄下，例如

如果掛載的目錄和Dockerfile中的COPY的目錄不一致， -v會替代COPY或者ADD ，例如現在Docker中COPY一個文件到容器/home目錄下

同目錄下start.sh內容是列印1

構建鏡像結束後，指定-v啟動，起始掛載另外一個目錄，目錄下start.sh內容是列印2

docker run參數中最後的COMMAND會覆蓋Dockerfile中指定的 CMD ，例如執行echo 2替換原始Dockerfile中的CMD echo 1，輸出結果是2且執行完畢後退出

對於Dockerfile中的 ENTRYPOINT 指定的啟動命令docker run的COMMAND不會覆蓋，如果要覆蓋Docker中的ENTRYPOINT需要指定docker run中的 --entrypoint 參數，格式是

測試一個Dockerfile輸出1

在docker run中使用--entrypoint覆蓋Dockerfile中的ENTRYPOINT

容器啟動後通過 docker ps 或者 docker container ls 查看容器，可以增加額外參數比如 -a 顯示所有容器，默認只顯示運行的容器，可以增加 --no-trunc 參數使得顯示結果不截斷，例如

顯示結果分別顯示了容器的ID，鏡像，執行命令，創建時間，狀態，埠映射（宿主機->容器）和容器名稱。對於已經運行的容器可以使用 docker stop 停止，如果在docker run時增加--rm參數則停止的容器保留不會自動刪除，例如

除了docker stop命令還有一種停止容器的命令 docker kill ，相比於docker stop，docker kill是 強制立即停止 ，而docker stop是先給了容器10秒（默認）的時間，使得容器有一定的時間處理、保存程序執行現場， 優雅的退出程序 ，例如

在容器停止之後可以使用 docker start 再啟動一個停止的容器，例如

除此之外可以使用 docker restart ，此時容器可以使停止的也可以是在運行中的，例如

查看容器詳情使用 docker inspect ，比如

在以上截取的內容中展示了容器詳情，包括容器id，創建時間，執行命令和參數，執行狀態，容器pid，落腳點，環境變數，網路設置，埠映射等，也可以使用Go語言風格輸出指定的詳情，比如分別只看容器的pid和容器的執行命令

容器是一個操作系統，可以進入這個操作系統查看容器的運行情況，有多種方式進入容器，其中主要是使用 docker exec 進入容器，在一個運行中的容器中執行一個命令，使用 -it 並帶有 /bin/bash 命令就可以進入容器，比如

除了/bin/bash也可以是其他命令掛載exec後面則可以直接對一個運行中的容器執行命令，比如查看容器的進入落腳點路徑，容器中的內存情況

當容器以後台 -d 運行時，日誌運行在容器內部，可以進入容器內部查看日誌，也可以使用 docker logs 查看日誌，以一個flask api介面的容器為例，日誌寫入文件，同時也會輸出在flask的控制台

創建Dockerfile以及構建鏡像，啟動容器

啟動一個腳本不斷請求api介面

進入容器內部查看日誌

另一種方式是直接使用 docker logs 命令，比如使用 -f 追蹤輸出，並且從最後的第1行開始輸出

此時宿主機的logs目錄下為空，容器中的logs目錄下存在detail.log文件，如果使用 -v 將宿主機目錄掛載到容器作為容器寫入的目錄，則容器中數據的變動會同步到本地，這樣可以直接在本地查看日誌，修改容器啟動為 -v 掛載的形式

此時本地logs目錄下開始產生日誌，且這個日誌和容器內的logs目錄下一致

如果容器內的內容改變了，此時刪除容器從鏡像重新啟動容器則改動的內容將不會存在，如果相對修改過的容器保留下來則可以從容器生成新的鏡像，先測試以下容器內修改在刪除的容器後將不再生效，在已有容器中使用pip安裝Python包

此時退出容器，並且刪除容器，最後從鏡像重新生成容器

此時進入容器檢查，並不存在pymongo包

如果要容器變化保存下來需要以這個新容器生成一個鏡像，使用 docker commit ，語法如下

以新安裝pymongo的容器為例，對新容器使用docker commmit

新生成的鏡像叫做xiaogp/my_image_test:v2

從新鏡像啟動容器並進入容器查看存在新安裝的pymongo

⑥ 網站中的jsp無法運行

網站中的jsp無法運行，表示當前的web容器可能編譯或者執行出錯，需從一下幾方面檢查。
1、web項目中jsp是否頁簽完整，包括一些標簽前後結束，是否編碼不支持中文等。
2、web容器是否已經配置正確，是否成功載入了web項目。
3、web容器載入項目成功，查看控制台或者tomcat容器下的log文件夾下的catalina.out文件，檢查日誌信息。
4、如果成功運行web項目，只是部分jsp不能運行，可以直接到web容易編譯的目錄查看具體哪個文件哪一行發生錯誤。

⑦ 如何查看c++ vector容器源代碼

1）.#include <iostream>
#include <vector>using namespace std;int main()
{
int a[7]={1,2,3,4,5,6,7};
vector<int> va(a,a+7); for(int i=0;i<va.size();i++)
cout<<va[i]<<" ";
} 這個是簡單的遍歷向量，輸出向量全部元素。 2).這是簡單的從向量 test.txt 文本文件中提取數據到向量 vector<string> va 中，然後在輸出。test.txt 的文本內容如下： 運行結果如下：//程序代碼如下：#include <iostream>
#include <vector>
#include <fstream>
#include <string>using namespace std;int main()
{
vector<string> va;
ifstream in("test.txt");
for(string s;in>>s;)
va.push_back(s);
for(int i=0;i<va.size();i++)
cout<<va[i]<<" ";
}

⑧ 如何查看一個jar文件是用什麼版本jdk編譯的

1.步驟如下：

在jar包中，用winrar解壓一個類文件，然後在命令行下面輸入
javap -verbose classname
會輸出一些信息，大致如下:

Compiled from "HtmlCrawer.Java"
public class org.eagleeye.html.HtmlCrawer extends java.lang.Object
SourceFile: "HtmlCrawer.java"
minor version: 0
major version: 50
Constant pool:
const #1 = class #2; // org/eagleeye/html/HtmlCrawer
const #2 = Asciz org/eagleeye/html/HtmlCrawer;
const #3 = class #4; // java/lang/Object
const #4 = Asciz java/lang/Object;
const #5 = Asciz client;
....

後面省略了，可以看到前面有兩行:
minor version: 0
major version: 50

2.解決問題：

我們在嘗鮮 JDK1.5 的時候，相信不少人遇到過 Unsupported major.minor version 49.0 錯誤，當時定會茫然不知所措。因為剛開始那會兒，網上與此相關的中文資料還不多，現在好了，網上一找就知道是如何解決，大多會告訴你要使用 JDK 1.4 重新編譯。那麼至於為什麼，那個 major.minor 究竟為何物呢？這就是本篇來講的內容，以使未錯而先知。

我覺得我是比較幸運的，因為在遇到那個錯誤之前已研讀過《深入 Java 虛擬機》第二版，英文原書名為《Inside the Java Virtual Machine》( Second Edition)，看時已知曉 major.minor 藏匿於何處，但沒有切身體會，待到與 Unsupported major.minor version 49.0 真正會面試，正好是給我驗證了一個事實。

首先我們要對 Unsupported major.minor version 49.0 建立的直接感覺是：JDK1.5 編譯出來的類不能在 JVM 1.4 下運行，必須編譯成 JVM 1.4 下能運行的類。(當然，也許你用的還是 JVM 1.3 或 JVM 1.2，那麼就要編譯成目標 JVM 能認可的類)。這也解決問題的方向。

3.major.minor 棲身於何處

何謂 major.minor，且又居身於何處呢？先感性認識並找到 major.minor 來。

寫一個 Java Hello World! 代碼，然後用 JDK 1.5 的編譯器編譯成，HelloWorld.java

public class HelloWorld

{

public static void main(String[] args)

{

System.out.println("Hello, World!");

}

}

public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } }

用 JDK 1.5 的 javac HelloWorld.java 編譯出來的位元組碼 HelloWorld.class 用 UltraEdit 打開來的內容如圖所示：

從上圖中我們看出來了什麼是 major.minor version 了，它相當於一個軟體的主次版本號，只是在這里是標識的一個 Java Class 的主版本號和次版本號，同時我們看到 minor_version 為 0x0000，major_version 為 0x0031，轉換為十制數分別為0 和 49，即 major.minor 就是 49.0 了。

4.何謂 major.minor 以及何用

Class 文件的第 5-8 位元組為 minor_version 和 major_version。Java class 文件格式可能會加入新特性。class 文件格式一旦發生變化，版本號也會隨之變化。對於 JVM 來說，版本號確定了特定的 class 文件格式，通常只有給定主版本號和一系列次版本號後，JVM 才能夠讀取 class 文件。如果 class 文件的版本號超出了 JVM 所能處理的有效范圍，JVM 將不會處理該 class 文件。

在 Sun 的 JDK 1.0.2 發布版中，JVM 實現支持從 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 發布版中的 JVM 都能夠支持版本從 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能夠支持從版本 45.0 到46.0 的 class 文件格式。

1.0 或 1.2 版本的編譯器能夠產生版本號為 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 編譯器默認產生版本號為 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 標志，1.2 版本的編譯器將產生版本號為 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能運行使用-target 1.2 標志所產生的 class 文件。

JVM 實現的 第二版中修改了對 class 文件主版本號和次版本號的解釋。對於第二版而言，class 文件的主版本號與 Java 平台主發布版的版本號保持一致(例如：在 Java 2 平台發布版上，主版本號從 45 升至 46)，次版本號與特定主平台發布版的各個發布版相關。因此，盡管不同的 class 文件格式可以由不同的版本號表示，但版本號不一樣並不代表 class 文件格式不同。版本號不同的原因可能只是因為 class 文件由不同發布版本的 java 平台產生，可能 class 文件的格式並沒有改變。

上面三段節選自《深入 Java 虛擬機》，啰嗦一堆，JDK 1.2 開啟了 Java 2 的時代，但那個年代仍然離我們很遠，我們當中很多少直接跳在 JDK 1.4 上的，我也差不多，只是項目要求不得不在一段時間里委屈在 JDK 1.3 上。不過大致我們可以得到的信息就是每個版本的 JDK 編譯器編譯出的 class 文件中都帶有一個版本號，不同的 JVM 能接受一個范圍 class 版本號，超出范圍則要出錯。不過一般都是能向後兼容的，知道 Sun 在做 Solaris 的一句口號嗎？保持對先前版本的 100% 二進制兼容性，這也是對客戶的投資保護。

四：編譯器比較及症節之所在

現在不妨從 JDK 1.1 到 JDK 1.7 編譯器編譯出的 class 的默認 minor.major version 吧。（又走到 Sun 的網站上翻騰出我從來都沒用過的古董來）

JDK 編譯器版本 target 參數 十六進制 minor.major 十進制 minor.major jdk1.1.8 不能帶 target 參數 00 03 00 2D 45.3 jdk1.2.2 不帶(默認為 -target 1.1) 00 03 00 2D 45.3 jdk1.2.2 -target 1.2 00 00 00 2E 46.0 jdk1.3.1_19 不帶(默認為 -target 1.1) 00 03 00 2D 45.3 jdk1.3.1_19 -target 1.3 00 00 00 2F 47.0 j2sdk1.4.2_10 不帶(默認為 -target 1.2) 00 00 00 2E 46.0 j2sdk1.4.2_10 -target 1.4 00 00 00 30 48.0 jdk1.5.0_11 不帶(默認為 -target 1.5) 00 00 00 31 49.0 jdk1.5.0_11 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.6.0_01 不帶(默認為 -target 1.6) 00 00 00 32 50.0 jdk1.6.0_01 -target 1.5 00 00 00 31 49.0 jdk1.6.0_01 -target 1.4 -source 1.4 00 00 00 30 48.0 jdk1.7.0 不帶(默認為 -target 1.6) 00 00 00 32 50.0 jdk1.7.0 -target 1.7 00 00 00 33 51.0 jdk1.7.0 -target 1.4 -source 1.4 00 00 00 30 48.0 Apache Harmony 5.0M3 不帶(默認為 -target 1.2) 00 00 00 2E 46.0 Apache Harmony 5.0M3 -target 1.4 00 00 00 30 48.0
上面比較是 Windows 平台下的 JDK 編譯器的情況，我們可以此作些總結：

1) -target 1.1 時 有次版本號，target 為 1.2 及以後都只用主版本號了，次版本號為 0
2) 從 1.1 到 1.4 語言差異比較小，所以 1.2 到 1.4 默認的 target 都不是自身相對應版本
3) 1.5 語法變動很大，所以直接默認 target 就是 1.5。也因為如此用 1.5 的 JDK 要生成目標為 1.4 的代碼，光有 -target 1.4 不夠，必須同時帶上 -source 1.4，指定源碼的兼容性，1.6/1.7 JDk 生成目標為 1.4 的代碼也如此。
4) 1.6 編譯器顯得較為激進，默認參數就為 -target 1.6。因為 1.6 和 1.5 的語法無差異，所以用 -target 1.5 時無需跟著 -source 1.5。
5) 注意 1.7 編譯的默認 target 為 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本號同對應 Sun 版本 JDK
7) 最後一點最重要的，某個版本的 JVM 能接受 class 文件的最大主版本號不能超過對應 JDK 帶相應 target 參數編譯出來的 class 文件的版本號。

上面那句話有點長，一口氣讀過去不是很好理解，舉個例子：1.4 的 JVM 能接受最大的 class 文件的主版本號不能超過用 1.4 JDK 帶參數 -target 1.4 時編譯出的 class 文件的主版本號，也就是 48。

因為 1.5 JDK 編譯時默認 target 為 1.5，出來的位元組碼 major.minor version 是 49.0，所以 1.4 的 JVM 是無法接受的，只有拋出錯誤。

那麼又為什麼從 1.1 到 1.2、從 1.2 到 1.3 或者從 1.3 到 1.4 的 JDK 升級不會發生 Unsupported major.minor version 的錯誤呢，那是因為 1.2/1.3/1.4 都保持了很好的二進制兼容性，看看 1.2/1.3/1.4 的默認 target 分別為 1.1/1.1/1.2 就知道了，也就是默認情況下1.4 JDK 編譯出的 class 文件在 JVM 1.2 下都能載入執行，何況於 JVM 1.3 呢？（當然要去除使用了新版本擴充的 API 的因素）

5：找到問題解決的方法

那麼現在如果碰到這種問題該知道如何解決了吧，還會像我所見到有些兄弟那樣，去找個 1.4 的 JDK 下載安裝，然後用其重新編譯所有的代碼嗎？其實大可不必如此費神，我們一定還記得 javac 還有個 -target 參數，對啦，可以繼續使用 1.5 JDK，編譯時帶上參數 -target 1.4 -source 1.4 就 OK 啦，不過你一定要對哪些 API 是 1.5 JDK 加入進來的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就會 method not found。目標 JVM 是 1.3 的話，編譯選項就用 -target 1.3 -source 1.3 了。

相應的如果使用 ant ，它的 javac 任務也可對應的選擇 target 和 source

<javac target="1.4" source="1.4" ............................/>

如果是在開發中，可以肯定的是現在真正算得上是 JAVA IDE 對於工程也都有編譯選項設置目標代碼的。例如 Eclipse 的項目屬性中的 Java Compiler 設置，如圖

自已設定編譯選項，你會看到選擇不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在變，你也可以手動調整那兩項，手動設置後你就不用很在乎用的什麼版本的編譯器了，只要求他生成我們希望的位元組碼就行了，再引申一下就是即使源代碼是用 VB 寫的，只要能編譯成 JVM 能執行的位元組碼都不打緊。在其他的 IDE 也能找到相應的設置對話框的。

其他時候，你一定要知道當前的 JVM 是什麼版本，能接受的位元組碼主版本號是多少（可對照前面那個表）。獲息當前 JVM 版本有兩種途徑：

第一：如果你是直接用 java 命令在控制台執行程序，可以用 java -version 查看當前的 JVM 版本，然後確定能接受的 class 文件版本

第二：如果是在容器中執行，而不能明確知道會使用哪個 JVM，那麼可以在容器中執行的程序中加入代碼System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，獲得 JVM 版本和能接受的 class 的版本號。

最後一絕招，如果你不想針對低版本的 JVM 用 target 參數重新編譯所有代碼；如果你仍然想繼續在代碼中用新的 API 的話；更有甚者，你還用了 JDK 1.5 的新特性，譬如泛型、自動拆裝箱、枚舉等的話，那你用 -target 1.4 -source 1.4 就沒法編譯通過，不得不重新整理代碼。那麼告訴你最後一招，不需要再從源代碼著手，直接轉換你所正常編譯出的位元組碼，繼續享用那些新的特性，新的 API，那就是：請參考之前的一篇日誌：Retrotranslator讓你用JDK1.5的特性寫出的代碼能在JVM1.4中運行，我就是這么用的，做好測試就不會有問題的。

6：再議一個實際發生的相關問題

這是一個因為拷貝 Tomcat 而產生的 Unsupported major.minor version 49.0 錯誤。情景是：我本地安裝的是 JDK 1.5，然後在網上找了一個 EXE 的 Tomcat 安裝文件安裝了並且可用。後來同事要一個 Tomcat，不想下載或安裝，於是根據我以往的經驗是把我的 Tomcat 整個目錄拷給他應該就行了，結果是拿到他那裡瀏覽 jsp 文件都出現 Unsupported major.minor version 49.0 錯誤，可以確定的是他安裝的是 1.4 的 JDK，但我還是有些納悶，先前對這個問題還頗有信心的我傻眼了。慣性思維是編譯好的 class 文件拿到低版本的 JVM 會出現如是異常，可現並沒有用已 JDK 1.5 編譯好的類要執行啊。

後來仔細看異常信息，終於發現了 %TOMCAT_HOME%commonlib ools.jar 這一眉目，因為 jsp 文件需要依賴它來編譯，打來這個 tools.jar 中的一個 class 文件來看看，49.0，很快我就明白原來這個文件是在我的機器上安裝 Tomcat 時由 Tomcat 安裝程序從 %JDK1.5%lib 目錄拷到 Tomcat 的 lib 目錄去的，造成在同事機器上編譯 JSP 時是 1.4 的 JVM 配搭著 49.0 的 tools.jar，那能不出錯，於是找來 1.4 JDK 的 tools.jar 替換了 Tomcat 的就 OK 啦。

⑨ 如何編譯Docker源碼

本文根據docker官方給出的docker代碼編譯環境搭建指南做更深入的分析。官方給出的指導比較簡單，但是由於國內的網路問題經常會編譯失敗，了解了編譯步驟後，也可以結合自身遇到的網路問題進行「規避」。
docker的編譯環境實際上是創建一個docker容器，在容器中對代碼進行編譯。 如果想快速的查看編譯環境搭建指導，而不關注環境搭建的機制和細節，可以直接跳到最後一章「總結」。

前提
機器上已經安裝了docker，因為編譯環境是個docker容器，所以要事先有docker（daemon），後面會創建個編譯環境容器，在容器裡面編譯代碼。本文中使用物理機，物理機上運行著docker （daemon）。
機器（物理機）上安裝了git 。 後續使用git下載docker源碼
機器（物理機）上安裝了make。
下載ubuntu 14.04的docker鏡像

下載docker源碼
git clone
會把代碼下載到當前目錄下，後面會把代碼拷貝到容器中。

編譯前分析
官方給的編譯方法是make build 和 make binary等。下面先分析Makefile，看懂Makefile後，編譯環境的准備流程就比較清楚了。

Makefile
在下載的docker源碼中可以看到它的Makefile，Makefile中比較關鍵的幾個參數：
DOCKER_MOUNT := $(if $(BIND_DIR),-v "$(CURDIR)/$(BIND_DIR):/go/src/github.com/docker/docker/$(BIND_DIR)") DOCKER_MOUNT 表示創建容器時的mount參數。因為編譯環境是一個容器，在後續的步驟中啟動容器時使用DOCKER_MOUNT參數，會將物理機上的目錄mount給容器容器，容器中該目錄是編譯生成docker二進制文件的目錄。
DOCKER_FLAGS := docker run --rm -i --privileged $(DOCKER_ENVS) $(DOCKER_MOUNT) 這是後面創建docker容器時的命令行的一部分，其中包含了前面的DOCKER_MOUNT參數。
DOCKER_IMAGE := docker-dev$(if $(GIT_BRANCH),:$(GIT_BRANCH)) 這是docker image參數，鏡像的名字是docker-dev，以當前git中docker版本作為tag名。這個鏡像是在make build一步做出來的。
DOCKER_RUN_DOCKER := $(DOCKER_FLAGS) "$(DOCKER_IMAGE)" 創建docker容器的命令行，組合了前面的DOCKER_FLAGS 和 DOCKER_IMAGE 。 從命令行中可以看出，啟動容器使用的參數有 --rm -i --privileged，使用了一些環境變數，還有使用了-v參數把物理機上目錄mount給容器，在容器中編譯好二進制文件後放到該目錄中，在物理機上就能獲得docker二進制文件。啟動的的docker 容器鏡像名字是docker-dev。下文會介紹docker-dev鏡像是怎麼來的。
由於官方給出的「構建編譯環境」的方法是執行 make build，下面在Makefile中看到build分支是這樣的：

make build時會調用 docker build -t "$(DOCKER_IMAGE)" . 去製作一個叫做DOCKER_IMAGE的鏡像。
進行源碼編譯的方式是執行 make binary來編譯代碼，在Makefile中make binary的分支如下：

make binary除了進行 make build以外，會執行$(DOCKER_RUN_DOCKER)，即上文提到的docker run命令行。由於執行過了build，會build出來docker-dev鏡像，所以在docker run時直接使用前面build出來的鏡像。docker run時的命令行參數是hack/make.sh binary。make binary的過程實際上是創建一個容器，在容器中執行hack/make.sh binary腳本。接下來會詳細介紹make build和make binary所做的內容。
make build
根據官方的指導，先執行make build來搭建編譯環境。上面分析了，make build實際上是製作了一個鏡像，這個鏡像里會包含編譯代碼所需的環境。下面來介紹下這個鏡像。

Dockerfile
在和Makefile相同的目錄下（源碼的根目錄），有Dockerfile。執行make build 相當於調用docker build，使用的就是該Dockerfile。Dockerfile中的幾個主要步驟（有些步驟這里略過）：
FROM ubuntu:14.04 使用ubuntu 14.04作為基礎鏡像；在宿主機上，要事先下載好ubuntu 14.04鏡像。
安裝一些編譯需要的軟體；
用git下載lvm2源碼，並編譯安裝；
下載並安裝GO 1.5.1；
安裝GO相關的tools 可以做code coverage test 、 go lint等代碼檢查
安裝registry和notary server；
安裝docker-py 後面跑集成測試用的
將物理機的contrib/download-frozen-image.sh 腳本拷貝到鏡像中/go/src/github.com/docker/docker/contrib/
運行contrib/download-frozen-image.sh 製作鏡像 實際上這一步只是下載了3個鏡像的tar文件。注意：docker build相當於創建一個臨時的容器（在臨時的容器中執行Dockerfile中的每一步，最後在保存成鏡像），「運行contrib/download-frozen-image.sh 製作鏡像」這個動作出現在Dockerfile中，相當於在docker build所創建的臨時的容器中下載docker鏡像，有docker-in-docker容器嵌套的概念。下一小節會對download-frozen-image.sh腳本做詳細分析。
ENTRYPOINT ["hack/dind"] 做出來的鏡像，使用它啟動的容器可以自動運行源碼目錄中的hack/dind腳本。 dind這個腳本是a wrapper script which allows docker to be run inside a docker container 。後面的小節會對hack/dind腳本做詳細的分析。
COPY . /go/src/github.com/docker/docker 把物理機上的docker源碼文件打入到鏡像中
download-frozen-image.sh腳本
上一小節里提到，在Dockerfile中，有一步會調用contrib/download-frozen-image.sh ，它主要作用是下載3個鏡像的tar包，供後續docker load。在Dockerfile中的調用方式如下：

download-frozen-image.sh腳本中會依次解析參數，其中/docker-frozen-images作為base dir，後面下載的東西全放到這里。之後的3個參數是鏡像，裡麵包含了鏡像名（例如busybox）、鏡像tag（例如latest）、鏡像id（例如），後面會在循環中依次下載這3個鏡像的tar文件。
download-frozen-image.sh腳本中會通過curl從registry上獲取如下信息：
token：獲取token，後面curl獲取的其他信息時都需要使用token。例如本例中 token='signature=,repository="library/busybox",access=read'
ancestryJson：把鏡像相關聯的歷史層次的id也都獲取到，因為每一層的tar都需要下載。本例中 ancestryJson='["", ""]'
這里可以看到這個鏡像只有2層，兩層的id這里都列了出來。 每個鏡像包含的層數不同，例如。第三個鏡像jess/unshare共有10層。
VERSION、json、tar: 每一層鏡像id的目錄下，都下載這3個文件，其中VERSION文件內容目前都是「1.0」，json文件是該層鏡像的json文件，tar文件是該層鏡像的真正內容，以.tar保存。
下載好的各層鏡像目錄結構如下：
$ls

$tree

hack/dind腳本
在Dockerfile中，ENTRYPOINT ["hack/dind"] ，表示在鏡像啟動後，運行該腳本，下面分析一下這個腳本的功能。
腳本在代碼根目錄下的hack目錄中，作者對腳本的描述是 DinD: a wrapper script which allows docker to be run inside a docker container.
就是可以在docker容器中創建docker容器。它就做了一個事，那就是在容器中創建好cgroup目錄，並把各個cgroup子系統mount上來。
為了方便理解，我們可以先看看物理機。在宿主機上如果創建docker容器，需要宿主機上必須事先mount cgroup子系統，因為cgroup是docker容器的一個依賴。同理docker-in-docker也要求外層的docker容器中有cgroup子系統，dind腳本在容器啟動後，先去/proc/1/cgroup中獲取cgroup子系統，然後依次使用mount命令，將cgroup mount上來，例如mount -n -t cgroup -o "cpuset" cgroup "/cgroup/cpuset"
最終在運行make build後，會製作出一個叫docker-dev的鏡像。
make binary
執行make binary 就可以編譯出docker二進制文件。編譯出來的二進制文件在源碼目錄下的bundles/1.10.0-dev/binary/docker-1.10.0-dev ，其中還包含md5和sha256文件。

Makefile中的binary
Makefile中關於make binary流程是

先執行build，即上一節介紹的，製作docker-dev編譯環境鏡像。
再執行DOCKER_RUN_DOCKER，創建容器，DOCKER_RUN_DOCKER就是執行docker run，使用docker-dev鏡像啟動容器，並且會mount -v 將容器生成二進制文件的路徑與宿主機共享。DOCKER_RUN_DOCKER在「編譯前分析」一章中有介紹。啟動的容器運行的命令行是 hack/make.sh binary 。docker run完整的形式如下：
docker run --rm -i --privileged -e BUILDFLAGS -e DOCKER_CLIENTONLY -e DOCKER_DEBUG -e DOCKER_EXECDRIVER -e DOCKER_EXPERIMENTAL -e DOCKER_REMAP_ROOT -e DOCKER_GRAPHDRIVER -e DOCKER_STORAGE_OPTS -e DOCKER_USERLANDPROXY -e TESTDIRS -e TESTFLAGS -e TIMEOUT -v "/home/mu/src/docker/docker/bundles:/go/src/github.com/docker/docker/bundles" -t "docker-dev:master" hack/make.sh binary
hack/make.sh腳本
上一節提到的make binary中創建的容器啟動命令是hack/make.sh binary，運行容器中的（docker源碼目錄下的）hack/make.sh腳本，參數為binary。
make.sh中根據傳入的參數組裝後續編譯用的flags（BUILDFLAGS），最後根據傳入的參數依次調用 hack/make/目錄下對應的腳本。例如我們的操作中傳入的參數只有一個binary。那麼在make.sh的最後，會調用hack/make/binary腳本。
hack/make/binary腳本中，就是直接調用go build進行編譯了，其中會使用BUILDFLAGS LDFLAGS LDFLAGS_STATIC_DOCKER等編譯選項。
如果最終生成的docker二進制文件不在bundles/1.10.0-dev/binary/目錄下，那麼可能是編譯參數BINDDIR設置的不正確，可以在執行make binary時增加BINDDIR參數，例如
make BINDDIR=. binary , 將BINDDIR設置為當前目錄。
總結
編譯步驟總結：
1、編譯前在物理機上安裝好make、git，並下載好docker代碼。下載好ubuntu:14.04鏡像
2、執行make build 。這步執行完會在物理機上創建出一個docker-dev的鏡像。
3、執行make binary 。 這步會使用docker-dev鏡像啟動一個容器，在容器中編譯docker代碼。編譯完成後在物理機上直接可以看到二進制文件。默認二進制文件在 bundles/1.10.0-dev/binary/目錄下
4、docker代碼里有很多test，可以使用此套編譯環境執行test，例如 make test 。 更多參數可以看Makefile
搭建環境心得：
1、在make build時，使用Dockerfile創建製作鏡像，這個鏡像有40多層，其中一層失敗就會導致整個build過程失敗。由於Dockerfile中很多步驟是要連到國外的網站去下載東西，很容易失敗。好在docker build有cache機制，如果前面的層成功了，下次重新build時會使用cache跳過，節省了很多時間。所以如果make build中途失敗（一般是由於國內連國外的網路原因），只要重新執行make build就會在上次失敗的地方繼續，多試幾次可以成功。
2、如果其他人已經build出了docker-dev鏡像，可以把它下載到自己的環境上。這樣在自己make build時，會跳過那些已經在本地存在的層，可以節省時間。
3、每一次編譯會自動刪除掉前面已經生成的二進制文件，所以不用擔心二進制文件不是最新的問題。

⑩ 如何查看 Docker 新版本中容器的名字空間

熟悉 Linux 技術的人都知道，容器只是利用名字空間進行隔離的進程而已，Docker 在容器實現上也是利用了 Linux 自身的技術。
有時候，我們需要在宿主機上對容器內進行一些操作，當然，這種繞過 Docker 的操作方式並不推薦。
如果你使用的是比較新的 Docker 版本，會尷尬的發現，直接使用系統命令，會無法訪問到容器名字空間。
這里，首先介紹下「 ip netns」 系列命令。這些命令負責操作系統中的網路名字空間。
首先，我們使用 「add」 命令創建一個臨時的網路名字空間。
ip netns add test

然後，使用 show 命令來查看系統中的網路名字空間，會看到剛創建的 test 名字空間。
ip netns show test

另外，一個很有用的命令是 exec，會在對應名字空間內執行命令。例如
ip netns exec test ifconfig

使用 del 命令刪除剛創建的 test 名字空間。
ip netns del test

接下來運行一個 Docker 容器，例如
docker run -it ubuntu

再次執行 ip netns show命令。很遺憾，這里什麼輸出都沒有。
原因在於，Docker 啟動容器後仍然會以進程號創建新的名字空間，但在較新的版本裡面，默認刪除了系統中的名字空間信息文件。
網路名字空間文件位於 /var/run/netns 下面，比如我們之前創建的 test 名字空間，則在這個目錄下有一個 test 文件。諸如 netns 類似的系統命令依靠這些文件才能獲得名字空間的信息。
在容器啟動後，查看這個目錄，會發現什麼都沒有。
OK，那讓我們手動重建它。
首先，使用下面的命令查看容器進程信息，比如這里的1234。
docker inspect --format='{{. State.Pid}} ' container_id 1234

接下來，在 /proc 目錄（保存進程的所有相關信息）下，把對應的網路名字空間文件鏈接到 /var/run/netns 下面
ln -s /proc/1234/ns/net /var/run/netns/

然後，就可以通過正常的系統命令來查看或訪問容器的名字空間了。例如
ip netns show 1234 ip netns exec 1234 ifconfig eth0 172.16.0.10/16...