1.equals方法用于比較對象的內容是否相等(覆蓋以后)
2.hashcode方法只有在集合中用到
3.當覆蓋了equals方法時,比較對象是否相等將通過覆蓋后的equals方法進行比較(判斷對象的內容是否相等)。
4.將對象放入到集合中時,首先判斷要放入對象的hashcode值與集合中的任意一個元素的hashcode值是否相等,如果不相等直接將該對象放入集合中。如果hashcode值相等,然后再通過equals方法判斷要放入對象與集合中的任意一個對象是否相等,如果equals判斷不相等,直接將該元素放入到集合中,否則不放入。
5.沒有覆蓋equals方法 采用對象內存地址是否相等來判斷對象是否相等。
因為是兩個新對象所以對象的內存地址不相等,所以stu1.equals(stu2) 是false。
6.線程A和B都要獲取對象O的鎖定,假設A獲取了對象O鎖,B將等待A釋放對O的鎖定,如果使用 synchronized ,如果A不釋放,B將一直等下去,不能被中斷如果使用ReentrantLock,如果A不釋放,可以使B在等待了足夠長的時間以后,中斷等待,而干別的事情
ReentrantLock獲取鎖定與三種方式:
a) lock(), 如果獲取了鎖立即返回,如果別的線程持有鎖,當前線程則一直處于休眠狀態,直到獲取鎖
b) tryLock(), 如果獲取了鎖立即返回true,如果別的線程正持有鎖,立即返回false;
c)tryLock(long timeout,TimeUnit unit), 如果獲取了鎖定立即返回true,如果別的線程正持有鎖,會等待參數給定的時間,
在等待的過程中,如果獲取了鎖定,就返回true,如果等待超時,返回false;
d) lockInterruptibly:如果獲取了鎖定立即返回,如果沒有獲取鎖定,當前線程處于休眠狀態,直到或者鎖定,
或者當前線程被別的線程中斷
synchronized是在JVM層面上實現的,不但可以通過一些監控工具監控synchronized的鎖定,而且在代碼執行時出現異常,
JVM會自動釋放鎖定,但是使用Lock則不行,lock是通過代碼實現的,要保證鎖定一定會被釋放,就必須將unLock()放到finally{}中
在資源競爭不是很激烈的情況下,Synchronized的性能要優于ReetrantLock,但是在資源競爭很激烈的情況下,Synchronized的性能會下降幾十倍,但是ReetrantLock的性能能維持常態;
在 JDK 中,主要由以下類來實現 Java 反射機制,這些類都位于 java.lang.reflect 包中:
Class 類:代表一個類。
Field 類:代表類的成員變量(成員變量也稱為類的屬性)。
Method 類:代表類的方法。
Constructor 類:代表類的構造方法。
Array 類:提供了動態創建數組,以及訪問數組的元素的靜態方法。
下面給出幾個例子看看 Reflection API 的實際運用:
一、通過 Class 類獲取成員變量、成員方法、接口、超類、構造方法等
在 java.lang.Object 類中定義了 getClass() 方法,因此對于任意一個 Java 對象,都可以通過此方法獲得對象的類型。 Class 類是 Reflection API 中的核心類,它有以下方法
getName() :獲得類的完整名字。
getFields() :獲得類的 public 類型的屬性。
getDeclaredFields() :獲得類的所有屬性。
getMethods() :獲得類的 public 類型的方法。
getDeclaredMethods() :獲得類的所有方法。
getMethod(String name, Class[] parameterTypes) :獲得類的特定方法, name 參數指定方法的名字, parameterTypes 參數指定方法的參數類型。
getConstructors() :獲得類的 public 類型的構造方法。
getConstructor(Class[] parameterTypes) :獲得類的特定構造方法, parameterTypes 參數指定構造方法的參數類型。
newInstance() :通過類的不帶參數的構造方法創建這個類的一個對象。
編寫Java反射程序的步驟:
1)必須首先獲取一個類的Class對象
例如:
1
2
3
|
Class c1 = Test. class ; Class c2 = Class.forName(“com.reflection.Test”); Class c3 = new Test().getClass(); |
2)然后分別調用Class對象中的方法來獲取一個類的屬性/方法/構造方法的結構
注意:如果要能夠正常的獲取類中方法/屬性/構造方法應該重點掌握如下的反射類
Field
Constructor
Method
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<servlet-mapping> <servlet-name></servlet-name> <url-pattern></url-pattern> </servlet-mapping> for (String elementA:str ) { System.out.print(elementA + " " ); } List<String> list = new ArrayList<String>(); for ( int i= 0 ; i<str.length; i++) { if (!list.contains(str[i])) { list.add(str[i]); } } Set<String> set = new HashSet<String>(); for ( int i= 0 ; i<str.length; i++) { set.add(str[i]); } |
spring有六種事務五種隔離級別
第一類:整型 byte short int long
第二類:浮點型 float double
第三類:邏輯型 boolean(它只有兩個值可取true false)
第四類:字符型 char
final修飾類中的方法
作用:可以被繼承,但繼承后不能被重寫。
final修飾類
作用:類不可以被繼承。
final修飾基本類型時候值不變,引用類型表示地址不變,就是new的時候那個是地址不能重新賦值
final修飾屬性你懂的
prepareStatement是預編譯的,先把這個SQL提交到數據庫中進行預處理,然后將其放到緩存里面,下次發現有相同的就不用編譯了,執行效率高,有語法提示方便檢查,參數是動態的,防止sql注入因為語法檢查
1
|
select * from tbName = ‘zck ' and passwd = ” or ‘1' = ‘ 1 '; |
statement就不是預編譯,而且需要手動檢查語法錯誤,屬于硬編碼
HashMap允許將null作為一個entry的key或者value,而Hashtable不允許
put方法
HashMap會對null值key進行特殊處理,總是放到table[0]位置put過程是先計算hash然后通過hash與table.length取摸計算index值,然后將key放到table[index]位置,當table[index]已存在其它元素時,會在table[index]位置形成一個鏈表,將新添加的元素放在table[index],原來的元素通過Entry的next進行鏈接,這樣以鏈表形式解決hash沖突問題,當元素數量達到臨界值(capactiy*factor)時,則進行擴容,是table數組長度變為table.length*2
get方法
同樣當key為null時會進行特殊處理,在table[0]的鏈表上查找key為null的元素
get的過程是先計算hash然后通過hash與table.length取摸計算index值,然后遍歷table[index]上的鏈表,直到找到key,然后返回HashMap和Hashtable的底層實現都是數組+鏈表結構實現的添加、刪除、獲取元素時都是先計算hash,根據hash和table.length計算index也就是table數組的下標,然后進行相應操作
索引大多數基于B樹
Servlet線程安全問題主要是由實例變量造成的,因此在Servlet中應避免使用實例變量。
如果應用程序設計無法避免使用實例變量,那么使用同步來保護要使用的實例變量,但為保證系統的最佳性能,應該同步可用性最小的代碼路徑。
寫一個單例模式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public static long recursive( int n) { if (n <= 0 ) return 0 ; if (n == 1 ) return 1 ; return recursive(n - 1 ) + recursive(n - 2 ); } public static long loop( int n) { if (n <= 0 ) return 0 ; if (n == 1 ) return 1 ; long fib1 = 0 ; long fib2 = 1 ; long sum = 0 ; for ( int i = 2 ; i <= n; i++) { sum = fib1 + fib2; fib1 = fib2; fib2 = sum; } return sum; } |
HashTable是一個線程安全的類,它使用synchronized來鎖住整張Hash表來實現線程安全,即每次鎖住整張表讓線程獨占。ConcurrentHashMap允許多個修改操作并發進行,其關鍵在于使用了鎖分離技術。它使用了多個鎖來控制對hash表的不同部分進行的修改。
ConcurrentHashMap內部使用段(Segment)來表示這些不同的部分,每個段其實就是一個小的Hashtable,它們有自己的鎖。只要多個修改操作發生在不同的段上,它們就可以并發進行。
有些方法需要跨段,比如size()和containsValue(),它們可能需要鎖定整個表而而不僅僅是某個段,這需要按順序鎖定所有段,操作完畢后,又按順序釋放所有段的鎖。這里“按順序”是很重要的,否則極有可能出現死鎖,在ConcurrentHashMap內部,段數組是final的,并且其成員變量實際上也是final的,但是,僅僅是將數組聲明為final的并不保證數組成員也是final的,這需要實現上的保證。
這可以確保不會出現死鎖,因為獲得鎖的順序是固定的
① ThreadLocal ② synchronized( ) ③ wait() 與 notify() ④ volatile
ThreadLocal
ThreadLocal 保證不同線程擁有不同實例,相同線程一定擁有相同的實例,即為每一個使用該變量的線程提供一個該變量值的副本,每一個線程都可以獨立改變自己的副本,而不是與其它線程的副本沖突。
優勢:提供了線程安全的共享對象
與其它同步機制的區別:同步機制是為了同步多個線程對相同資源的并發訪問,是為了多個線程之間進行通信;
而 ThreadLocal 是隔離多個線程的數據共享,從根本上就不在多個線程之間共享資源,這樣當然不需要多個線程進行同步了。
volatile
volatile 修飾的成員變量在每次被線程訪問時,都強迫從共享內存中重讀該成員變量的值。而且,
當成員變量發生變化時,強迫線程將變化值回寫到共享內存。
優勢:這樣在任何時刻,兩個不同的線程總是看到某個成員變量的同一個值。
緣由:Java 語言規范中指出,為了獲得最佳速度,允許線程保存共享成員變量的私有拷貝,
而且只當線程進入或者離開同步代碼塊時才與共享成員變量的原始值對比。
這樣當多個線程同時與某個對象交互時,就必須要注意到要讓線程及時的得到共享成員變量的變化。
而 volatile 關鍵字就是提示 VM :對于這個成員變量不能保存它的私有拷貝,而應直接與共享成員變量交互。
使用技巧:在兩個或者更多的線程訪問的成員變量上使用 volatile 。
當要訪問的變量已在 synchronized 代碼塊中,或者為常量時,不必使用。
線程為了提高效率,將某成員變量(如A)拷貝了一份(如B),線程中對A的訪問其實訪問的是B。只在某些動作時才進行A和B的同步,因此存在A和B不一致的情況。volatile就是用來避免這種情況的。
volatile告訴jvm,它所修飾的變量不保留拷貝,直接訪問主內存中的(讀操作多時使用較好;線程間需要通信,本條做不到)
Volatile 變量具有 synchronized 的可見性特性,但是不具備原子特性。
這就是說線程能夠自動發現 volatile 變量的最新值。Volatile 變量可用于提供線程安全,但是只能應用于非常有限的一組用例:多個變量之間或者某個變量的當前值與修改后值之間沒有約束。
您只能在有限的一些情形下使用 volatile 變量替代鎖。要使 volatile 變量提供理想的線程安全,必須同時滿足下面兩個條件:
對變量的寫操作不依賴于當前值;該變量沒有包含在具有其他變量的不變式中。
sleep() vs wait()
sleep是線程類(Thread)的方法,導致此線程暫停執行指定時間,把執行機會給其他線程,但是監控狀態依然保持,到時后會自動恢復。調用sleep不會釋放對象鎖。
wait是Object類的方法,對此對象調用wait方法導致本線程放棄對象鎖,進入等待此對象的等待鎖定池,只有針對此對象發出notify方法(或notifyAll)后本線程才進入對象鎖定池準備獲得對象鎖進入運行狀態。 (如果變量被聲明為volatile,在每次訪問時都會和主存一致;如果變量在同步方法或者同步塊中被訪問,當在方法或者塊的入口處獲得鎖以及方法或者塊退出時釋放鎖時變量被同步。)
http://www.yjbys.com/news/202750.html
客戶程序要先得到具體容器角色,然后再通過具體容器角色得到具體迭代器角色
Iterator it=new ArrayList.iterator();
1) 訪問一個容器對象的內容而無需暴露它的內部表示。
2) 支持對容器對象的多種遍歷。
3) 為遍歷不同的容器結構提供一個統一的接口(多態迭代)。
使用new關鍵字 } → 調用了構造函數
使用Class類的newInstance方法 } → 調用了構造函數
使用Constructor類的newInstance方法 } → 調用了構造函數
使用clone方法 } → 沒有調用構造函數
使用反序列化 } → 沒有調用構造函數
1
|
Employee emp2 = (Employee) Class.forName(“com.Employee”).newInstance(); |
或者
1
2
3
|
Employee emp2 = Employee. class .newInstance(); Constructor constructor = Employee. class .getConstructor(); Employee emp3 = constructor.newInstance(); |
使用clone方法,我們需要先實現Cloneable接口并實現其定義的clone方法
1
|
Employee emp4 = (Employee) emp3.clone(); |
程序在啟動的時候,并不會一次性加載程序所要用的所有class文件,而是根據程序的需要,通過Java的類加載機制(ClassLoader)來動態加載某個class文件到內存當中的,從而只有class文件被載入到了內存之后,才能被其它class所引用。所以ClassLoader就是用來動態加載class文件到內存當中用的。
Bootstrap ClassLoader:稱為啟動類加載器,是Java類加載層次中最頂層的類加載器,負責加載JDK中的核心類庫,如:rt.jar、resources.jar、charsets.jar等Extension ClassLoader:稱為擴展類加載器,負責加載Java的擴展類庫, 默認加載JAVA_HOME/jre/lib/ext/目下的所有jar。
App ClassLoader:稱為系統類加載器,負責加載應用程序classpath目錄下的所有jar和class文件。
因為這樣可以避免重復加載,當父親已經加載了該類的時候,就沒有必要子ClassLoader再加載一次。
考慮到安全因素,我們試想一下,如果不使用這種委托模式,那我們就可以隨時使用自定義的String來動態替代java核心api中定義的類型,這樣會存在非常大的安全隱患,而雙親委托的方式,就可以避免這種情況,因為String已經在啟動時就被引導類加載器(Bootstrcp ClassLoader)加載,所以用戶自定義的ClassLoader永遠也無法加載一個自己寫的String,除非你改變JDK中ClassLoader搜索類的默認算法。
1、request對象 客戶端請求,此請求會包含來自GET/POST請求的參數通過它才能了 解到客戶的需求,然后做出響應。
2、response對象 響應客戶請求的有關信息
3、session對象 它指的是客戶端與服務器的一次會話,從客戶端連到服務器的一個 WebApplication開始,直到客戶端與服務 器斷開連接為止。
4、out對象 它是JspWriter類的實例,是向客戶端輸出內容常用的對象
5、page對象 它是指向當前JSP頁面本身,有點象類中的this指針,它是 java.lang.Object類的實例
6、application對象 它實現了用戶間數據的共享,可存放全局變量。它開始于服務器的啟動,直到服務器的關閉
7、exception對象 它是一個例外對象,當一個頁面在運行過程中發生了例外,就產生這個對象。
8、pageContext對象 它提供了對JSP頁面內所有的對象及名字空間的訪問
9、config對象 它是在一個Servlet初始化時,JSP引擎向它傳遞信息用的
js有個函數 isNaN(val)//如果是數字則返回 false
有XMLDOM解析、SAX解析、StAX解析
XMLDOM:(XMLDocumentObjectModel)處理大型文件時其性能下降的非常厲害。這個問題是由DOM的樹結構所造成的,這種結構占用的內存較多,而且DOM必須在解析文件之前把整個文檔裝入內存,適合對XML的隨機訪問;
SAX:(SimpleAPIforXML)不同于DOM,SAX是事件驅動型的XML解析方式。它順序讀取XML文件,不需要一次全部裝載整個文件。當遇到像文件開頭,文檔結束,或者標簽開頭與標簽結束時,它會觸發一個事件,用戶通過在其回調事件中寫入處理代碼來處理XML文件,適合對XML的順序訪問;
StAX:(StreamingAPIforXML)與其他方法的區別就在于應用程序能夠把XML作為一個事件流來處理,無論從性能還是可用性上都優于其他方法;
thread.getState()
以上是小編給大家整理的有關java面試題,希望對大家有所幫助,如果大家有任何疑問歡迎給我留言,小編會及時回復大家的!
原文鏈接:http://blog.csdn.net/u013086392/article/details/52398796