一、單選題（共21題，每題5分）
A
暫無
1 public class A2{ 2 public static void main(String[] args){ 3 int[] a={2,4,6,8,3,6,9,12}; 4 doSomething(a,0,a.length-1); 5 for(int i=0;i=x){ 6 swap(a,i,j); 7 i++;//交換了幾次 8 } 9 }//把最大的放到最后 10 swap(a,i,end);//把最大的放到i的位置 11 return i; 12 } 13 14 private static void swap(int[] a,int i,int j) 15 { 16 int tmp=a[i]; 17 a[i]=a[j]; 18 a[j]=tmp; 19 } 20 } 21 ```
Hbase是一個面向列分布式數據庫，和hive不同的是，hbase能夠在它的數據庫上實時運行，而不是運行mapreduce任務發生的
以下JAVA程序的輸出是什么（）
1 <pre class="prettyprint">public class HelloSogou{ 2 public static synchronized void main(String[] a){ 3 Thread t=new Thread(){ 4 public void run(){Sogou();} 5 }; 6 t.run(); 7 System.out.print("Hello"); 8 } 9 static synchronized void Sogou(){ 10 System.out.print("Sogou"); 11 } 12 }
本題考查線程的基本知識。線程與進程在概念上是相關的，線程是由表示程序運行狀態的寄存器、程序計數器、棧指針以及堆棧組成，它不包含進程地址空間中的代碼 和數據。代碼所操作的數據是Java線程模型中的一個組成部分，數據與代碼是獨立的。數據可以被多個線程共享，也可不共享。Java語言中提供兩種創建線 程的方法，－種是通過繼承Thread類創建線程，另－種是通過實現Runnable接口來創建線程。
Android中實現序列化有兩個選擇：一是實現Serializable接口（是JavaSE本身就支持的），一是實現Parcelable接口（是Android特有功能，效率比實現Serializable接口高效，可用於Intent數據傳遞，也可以用於進程間通信（IPC））。實現Serializable接口非常簡單，聲明一下就可以了，而實現Parcelable接口稍微復雜一些，但效率更高，推薦用這種方法提高性能。
注：Android中Intent傳遞對象有兩種方法：一是Bundle.putSerializable(Key，Object)，另一種是Bundle.putParcelable(Key，Object)。當然這些Object是有一定的條件的，前者是實現了Serializable接口，而后者是實現了Parcelable接口。
暫無
Java是一門面向對象的編程語言，下面關鍵字中能夠表示Java面向對象的特性是（）
A
死鎖不僅可以發生在多線程中，也可以發生在多個進程中。只要是因爭搶資源導致互相等待，無外力作用無法前進的都可以稱為死鎖
暫無
一個jvm中默認的classloader有Bootstrap ClassLoader、Extension ClassLoader、App ClassLoader，分別各司其職：
- Bootstrap ClassLoader 負責加載java基礎類，主要是 %JRE_HOME/lib/ 目錄下的rt.jar、resources.jar、charsets.jar和class等
- Extension ClassLoader 負責加載java擴展類，主要是 %JRE_HOME/lib/ext 目錄下的jar和class
- App ClassLoader 負責加載當前java應用的classpath中的所有類。
classloader 加載類用的是全盤負責委托機制。所謂全盤負責，即是當一個classloader加載一個Class的時候，這個Class所依賴的和引用的所有 Class也由這個classloader負責載入，除非是顯式的使用另外一個classloader載入。
所以，當我們自定義的classloader加載成功了com.company.MyClass以后，MyClass里所有依賴的class都由這個classLoader來加載完成。
SSL是解決傳輸層安全問題的一個主要協議，其設計的初衷是基於TCP協議之上提供可靠的端到端安全服務。應用SSL協議最廣泛的是HTTPS，它為客戶瀏覽器和Web服務器之間交換信息提供安全通信支持。它使用TCP的443端口發送和接收報文。
- ①．繼承java．lang．Thread類，並重寫run（ ）方法
- ②．繼承java．lang．Runnable類，並重寫start（ ）方法
- ③．實現java．lang．Thread接口，並實現run（ ）方法
- ④．實現java．lang．Runable接口．並實現run（ ）方法
用Thread類的構造方法Thread(Runnable target)創建線程對象時，構造方法中的參數必須是一個具體的對象，該對象稱作線程的目標對象，創建目標對象的類必須要實現Runnable接口。
如果希望在網絡中通過某個類的對象包裝數據進行傳輸，那么這個類需要實現下面哪個接口？（）
Windows下是ipconfig，Linux下是ifconfig
暫無
答案：B解析：根據《系統集成項目管理工程師教程（第2版）》第137頁，繼承表示類之間的層次關系（父類與子類），這種關系使得某類對象可以集成另外一類對象的特征。所以繼承關系中共有類屬性只要在父類中進行說明即可，子類不需要了。
二、多選題（共8題，每題5分）
收到很多贊，感謝諸君閱讀捧場
在此針對評論區的一些意見發表如下聲明：
- 這個回答不會給你解釋題目與分析解題過程。這個回答的目的是科普。為的是從根本上向大家解釋清楚Unicode的玩法。如果讀者只是想了解解題過程和選項分析，請看本題的推薦答案。
- 一些朋友說這個答案是復制粘貼過來的。我想一千個讀者有一千個哈姆雷特。我無論說什么其實都無法改變讀者內心認定的那個結論。所以，大家開心就好。為了這個目的，大家不妨先問問自己是不是真的想要了解Unicode的基礎知識？如果是，那么歡迎您繼續下面的旅程。
很多人都把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進行自如轉換。
答案:ABCD 做這題其實要區分:C的過程，C++的函數，Java的方法。再看題目，就知道考點了。 java不允許單獨的方法，過程或函數存在,需要隸屬於某一類中。——AB錯 java語言中的方法屬於對象的成員,而不是類的成員。不過，其中靜態方法屬於類的成員。——C錯 D問的是java調用方法和C調用過程,C+ + 的函數一樣？肯定不一樣。錯
暫無
異常處理的過程中，你遵循那些好的實踐？
- 異常處理在項目設計中是非常關鍵的，所以精通異常處理是十分必要的。異常處理有很多最佳實踐，下面列舉集中，它們提高你代碼的健壯性和靈活性：
- 調用方法的時候返回布爾值來代替返回null，這樣可以 NullPointerException。由於空指針是java異常里最惡心的異常。
- catch塊里別不寫代碼。空catch塊是異常處理里的錯誤事件，因為它只是捕獲了異常，卻沒有任何處理或者提示。通常你起碼要打印出異常信息，當然你最好根據需求對異常信息進行處理。
- 能拋受控異常（checked Exception）就盡量不拋受非控異常(checked Exception)。通過去掉重復的異常處理代碼，可以提高代碼的可讀性。
- 絕對不要讓你的數據庫相關異常顯示到客戶端。由於絕大多數數據庫和SQLException異常都是受控異常，在Java中，你應該在DAO層把異常信息處理，然后返回處理過的能讓用戶看懂並根據異常提示信息改正操作的異常信息。
- 在Java中，一定要在數據庫連接，數據庫查詢，流處理后，在finally塊中調用close()方法。
bean是Struts1的標簽，先下載struts-taglib-1.3.10.jar，然后添加到lib.
測試代碼：
pageEncoding="gbk"%>
RDB 優缺點
- RDB 會生成多個數據文件，每個數據文件都代表了某一個時刻中 redis 的數據，這種多個數據文件的方式，非常適合做冷備，可以將這種完整的數據文件發送到一些遠程的安全存儲上去，比如說 Amazon 的 S3 雲服務上去，在國內可以是阿里雲的 ODPS 分布式存儲上，以預定好的備份策略來定期備份 redis 中的數據。
- RDB 對 redis 對外提供的讀寫服務，影響非常小，可以讓 redis 保持高性能，因為 redis 主進程只需要 fork 一個子進程，讓子進程執行磁盤 IO 操作來進行 RDB 持久化即可。
- 相對於 AOF 持久化機制來說，直接基於 RDB 數據文件來重啟和恢復 redis 進程，更加快速。
- 如果想要在 redis 故障時，盡可能少的丟失數據，那么 RDB 沒有 AOF 好。一般來說，RDB 數據快照文件，都是每隔 5 分鍾，或者更長時間生成一次，這個時候就得接受一旦 redis 進程宕機，那么會丟失最近 5 分鍾的數據。
- RDB 每次在 fork 子進程來執行 RDB 快照數據文件生成的時候，如果數據文件特別大，可能會導致對客戶端提供的服務暫停數毫秒，或者甚至數秒。
程序計數器一般不會溢出。
三、判斷題（共1題，每題5分）
1、表的設計：
①用戶表usertable ，字段id,name,point,以及記錄該用戶是否曾經兌換過魔盒的標志字段hasdown,用0表示沒有下過，1表示下過
②魔盒表boxtable,字段allnumber表示總數，remainnumber表示所省的魔盒數量
③訂單表ordertable,字段id,userid,ordertime表示下單時間
2、並發過程，當所有用戶同時訪問數據庫，操作魔盒表和用戶表時為了保證事務的一致性，有必要在業務邏輯處理的地方，即更改魔盒表中魔盒數量的代碼塊或接口和對用戶表信息的處理地方處都要加上同步機制，事務回滾等措施
3、用到的事務
判斷用戶信息：積分是否大於99，是否曾經兌換過魔盒（hasdown是否為0），如果積分夠又沒兌換過，那么在兌換時用戶表里的積分數要減去99，並且置hasdown為1
操作魔盒表：判斷魔盒剩余數是否大於0，如果大於0就進行兌換，並使魔盒數減1，
訂單表：當以上兩個事務均完成時再向訂單表里插入一條記錄，包括用戶id，下單時間
附：接口
Public void order(User user, Box box);