【288天】我愛刷題系列047（2017.11.20）

叨叨兩句

1. 搞定~

牛客網——java專項練習027

1

java中下面哪一個能建立並啓動線程（）

public class MyRunnable implements Runnable          { 
     public void run()             { 
         //some code here 
     } 
 }

正確答案: C

1. new Runnable(MyRunnable).start()

2. new Thread(MyRunnable).run()

3. new Thread(new MyRunnable()).start()

4. new MyRunnable().start()

首先：建立並啓動線程的過程爲：定義線程—》實例化線程—》啓動線程。
一 、定義線程： 一、擴展java.lang.Thread類。 二、實現java.lang.Runnable接口。
2、實例化線程： 一、若是是擴展java.lang.Thread類的線程，則直接new便可。
                 二、若是是實現了java.lang.Runnable接口的類，則用Thread的構造方法：
        Thread(Runnable target) 
        Thread(Runnable target, String name) 
        Thread(ThreadGroup group, Runnable target) 
        Thread(ThreadGroup group, Runnable target, String name) 
        Thread(ThreadGroup group, Runnable target, String name, long stackSize)
因此A、D的實例化線程錯誤。
3、啓動線程： 在線程的Thread對象上調用start()方法，而不是run()或者別的方法。
因此B的啓動線程方法錯誤。

2

下面哪一個不對？
正確答案: C 你的答案: C (正確)

1. RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

2. 1. method is not required to declare in its throws clause any subclasses of RuntimeExeption that might be thrown during the execution of the method but not caught

3. An RuntimeException is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

4. NullPointerException is one kind of RuntimeException

運行時異常： 都是RuntimeException類及其子類異常，如NullPointerException(空指針異常)、IndexOutOfBoundsException(下標越界異常)等，這些異常是不檢查異常，程序中能夠選擇捕獲處理，也能夠不處理。這些異常通常是由程序邏輯錯誤引發的，程序應該從邏輯角度儘量避免這類異常的發生。
       運行時異常的特色是Java編譯器不會檢查它，也就是說，當程序中可能出現這類異常，即便沒有用try-catch語句捕獲它，也沒有用throws子句聲明拋出它，也會編譯經過。 
非運行時異常 （編譯異常）： 是RuntimeException之外的異常，類型上都屬於Exception類及其子類。從程序語法角度講是必須進行處理的異常，若是不處理，程序就不能編譯經過。如IOException、SQLException等以及用戶自定義的Exception異常，通常狀況下不自定義檢查異常。

3

有如下程序段， 則下面正確的選項是（）

public class MyThead extends Thread{
    public static void main(String[] args) {
        MyThead t=new MyThead();
        MyThead s=new MyThead();
        t.start();
        System.out.println("one.");
        s.start();
        System.out.println("two.");
    }
    public void run() {
        System.out.println("Thread");
    }
}

正確答案: B C D

1. 編譯失敗

2. 程序運行可能結果爲：

one.
Thread
two.
Thread

1. 程序運行可能結果是：

one.
two.
Thread
Thread

1. 程序運行結果不穩定

start()是開啓線程，等待得到時間片，一到得到時間片就執行。因此可能一開啓就得到了時間片執行，也有可能等到two輸出後纔得到了時間片。因此BC均可能，因此D也正確。

4

在Java語言中，下列關於字符集編碼（Character set encoding）和國際化（i18n）的問題，哪些是正確的？
正確答案: C D

1. 每一箇中文字符佔用2個字節，每一個英文字符佔用1個字節

2. 假設數據庫中的字符是以GBK編碼的，那麼顯示數據庫數據的網頁也必須是GBK編碼的。

3. Java的char類型，一般以UTF-16 Big Endian的方式保存一個字符。

4. 實現國際化應用經常使用的手段是利用ResourceBundle類

A 顯然是錯誤的，Java一概採用Unicode編碼方式，每一個字符不管中文仍是英文字符都佔用2個字節。
B 也是不正確的，不一樣的編碼之間是能夠轉換的，一般流程以下：
將字符串S以其自身編碼方式分解爲字節數組，再將字節數組以你想要輸出的編碼方式從新編碼爲字符串。
例：String newUTF8Str = new String(oldGBKStr.getBytes("GBK"), "UTF8");
C 是正確的。Java虛擬機中一般使用UTF-16的方式保存一個字符
D 也是正確的。ResourceBundle可以依據Local的不一樣，選擇性的讀取與Local對應後綴的properties文件，以達到國際化的目的。

不少人都把Unicode編碼掛在嘴邊，其實我們現實生活中遇到的編碼基本都是Unicode的
由於Unicode兼容了大多數老版本的編碼規範例如 ASCII
Unicode編碼定義了這個世界上幾乎全部字符（就是你眼睛看到的長那個樣子的符號）的數字表示
也就是說Unicode爲每一個字符發了一張身份證，這張身份證上有一串惟一的數字ID肯定了這個字符
在這個紛亂世界上存在的惟一性。Unicode給這串數字ID起了個名字叫［碼點］（Code Point）
而不少人說的編碼實際上是想表達［Unicode轉換格式］（即UTF，Unicode Transformation Formats）
有沒有以爲眼前一亮豁然開朗？沒錯 這就是咱們看到的UTF-8/UTF-16/UTF-32的前綴來源
這個［Unicode轉換格式］的存在是爲了解決［碼點］在計算機中的二進制表現形式而設計的
畢竟咱們的機內表示涉及存儲位寬，兼容古老編碼格式，碼點是數值過大的罕見字符等問題
［碼點］通過映射後獲得的二進制串的轉換格式單位稱之爲［碼元］（Code Unit）。也就是說若是有一種UTF的碼點二進制表示有n字節，其碼元爲8位（1個byte），那麼其擁有碼元n個。每種UTF的碼元都不一樣，其寬度被做爲區分寫在了UTF的後綴——這就是UTF-8/UTF-16/UTF-32的由來。UTF-8的碼元是8位的，UTF-16的碼元是16位的。大部分的編程語言採用16位的碼元做爲機內表示。這就是咱們在各類語言中調用獲取一個字符串中character的數量時會出現這麼多混亂的緣由。事實上咱們調用這些方法時取得的不是字符個數，而是碼元個數！一旦咱們的字符串中包含了位於基本平面以外的碼點，那麼就會須要更多的碼元來表示，這個時候就會出現測試時常見的困惑——爲什麼return的字符數比實際字符數要多？因此實際寫代碼時要特別注意這個問題。
採起不一樣的映射方式能夠獲得不一樣格式的二進制串，可是他們背後所表示的［碼點］永遠是一致的就好像你換身份證可是身份證號不變同樣。因爲平時人們誤把［轉換格式］也稱爲［編碼］，因此形成今天Unicode／UTF傻傻分不清楚且遣詞造句運用混亂的悲桑局面。
Unicode 編碼 發展到今天 擴展到了 21 位（從 U+0000 到 U+10FFFF ）。這一點很重要： Unicode 不是 16 位的編碼， 它是 21 位的。這 21 位提供了 1,114,112 個碼點，其中，只有大概 10% 正在使用，因此還有至關大的擴充空間。
編碼空間被分紅 17 個平面（plane），每一個平面有 65,536 個字符（正好填充2個字節，16位）。0 號平面叫作「基本多文種平面」（ BMP, Basic Multilingual Plane ），涵蓋了幾乎全部你能遇到的字符，除了 emoji（emoji位於1號平面 - -）。其它平面叫作補充平面，大可能是空的。
總結一下各類編碼格式的特質：

UTF-32
最清楚明瞭的一個 UTF 就是 UTF-32 ：它在每一個碼點上使用整 32 位。32 大於 21，所以每個 UTF-32 值均可以直接表示對應的碼點。儘管簡單，UTF-32卻幾乎歷來不在實際中使用，由於每一個字符佔用 4 字節太浪費空間了。


UTF-16 以及「代理對」（ Surrogate Pairs ）的概念
UTF-16要常見得多，它是根據有 16 位固定長度的碼元（ code units ）定義的。UTF-16 自己是一種長度可變的編碼。基本多文種平面（BMP）中的每個碼點都直接與一個碼元相映射。鑑於 BMP 幾乎囊括了全部常見字符，UTF-16 通常只須要 UTF-32 一半的空間。其它平面裏不多使用的碼點都是用兩個 16 位的碼元來編碼的，這兩個合起來表示一個碼點的碼元就叫作代理對（ surrogate pair ）。

UTF-8
UTF-8 使用一到四個字節來編碼一個碼點。從 0 到 127 的這些碼點直接映射成 1 個字節（對於只包含這個範圍字符的文原本說，這一點使得 UTF-8 和 ASCII 徹底相同）。接下來的 1,920 個碼點映射成 2 個字節，在 BMP 裏全部剩下的碼點須要 3 個字節。Unicode 的其餘平面裏的碼點則須要 4 個字節。UTF-8 是基於 8 位的碼元的，所以它並不須要關心字節順序（不過仍有一些程序會在 UTF-8 文件里加上多餘的 BOM）。

有效率的空間使用（僅就西方語言來說），以及不須要操心字節順序問題使得 UTF-8 成爲存儲和交流 Unicode 文本方面的最佳編碼。它也已是文件格式、網絡協議以及 Web API 領域裏事實上的標準了。
咱們的JVM中保存碼點是UTF16的轉換格式，從char的位寬爲16位也能夠看得出來。因爲絕大部分編碼的碼點位於基本平面，因此使用16位能夠幾乎表示全部經常使用字符。這就是許多語言編譯器或運行時都使用UTF16的緣由。英文在使用UTF16時也是2字節表示的。當咱們想要使用其餘平面的字符時，碼元超過2個字節，就須要使用代理對在語言中的特定表示方式，譬如‘\U112233’之類的。
使用UTF8時，經常使用的Alphabet和Numeric都在前127字節，被有效率地用一個字節表示。而咱們的中文因爲排在1920個碼點以後，因此使用3個字節表示，這方面就比UTF16轉換格式耗費更多空間。
最後，不論使用哪一種UTF轉換格式，都是程序員本身能夠選擇的一種表達方式而已。咱們能夠經過Java方便的API進行自如轉換