Ⅰ 四道Java基礎題，你能做對幾道
符的使用
首先看一段比較有意思的代碼
[java] view plain
Integer a = 1000,b=1000;
Integer c = 100,d=100; public void mRun(final String name){
new Runnable() {
public void run() {
System.out.println(name);
}
};
}
System.out.println(a==b);
System.out.println(c==d);
如果這道題你能得出正確答案，並能了解其中的原理的話。說明你基礎還可以。如果你的答案 是 true 和true的話，你的基礎就有所欠缺了。
首先公布下答案， 運行代碼，我們會得到 false true。我們知道==比較的是兩個對象的引用，這里的abcd都是新建出來的對象，按理說都應該輸入false才對。這就是這道題的有趣之處，無論是面試題還是論壇討論區，這道題的出場率都很高。原理其實很簡單，我們去看下Integer.java這個類就瞭然了。
[java] view plain
public static Integer valueOf(int i) {
return i >= 128 || i < -128 ? new Integer(i) : SMALL_VALUES[i + 128];
}
/**
* A cache of instances used by {@link Integer#valueOf(int)} and auto-boxing
*/
private static final Integer[] SMALL_VALUES = new Integer[256];
static {
for (int i = -128; i < 128; i++) {
SMALL_VALUES[i + 128] = new Integer(i);
}
}
當我們聲明一個Integer c = 100;的時候。此時會進行自動裝箱操作，簡單點說，也就是把基本數據類型轉換成Integer對象，而轉換成Integer對象正是調用的valueOf方法，可以看到，Integer中把-128-127 緩存了下來。官方解釋是小的數字使用的頻率比較高，所以為了優化性能，把這之間的數緩存了下來。這就是為什麼這道題的答案回事false和ture了。當聲明的Integer對象的值在-128-127之間的時候，引用的是同一個對象，所以結果是true。
2String
接著看代碼
[java] view plain
String s1 = "abc";
String s2 = "abc";
String s3 = new String("abc");
System.out.println(s1 == s2);
System.out.println(s1 == s3);
大家又來猜一猜這道題的答案是什麼？
按照==的語法來看， 首先s1、s2、s3是三個不同的對象，常理來說，輸出都會是false。然而程序的運行結果確實true、false。第二個輸出false可以理解，第一個輸出true就又讓人費解了。我們知道一些基本類型的變數和對象的引用變數都是在函數的棧內存中分配，而堆內存中則存放new 出來的對象和數組。然而除此之外還有一塊區域叫做常量池。像我們通常想String s1 = "abc"; 這樣申明的字元串對象，其值就是存儲在常量池中。當我們創建String s1 = "abc"這樣一個對象之後，"abc"就存儲到了常量池（也可叫做字元串池）中，當我們創建引用String s2 = "abc" 的時候，Java底層會優先在常量池中查找是否存在"abc"，如果存在則讓s2指向這個值，不會重新創建，如果常量池中沒有則創建並添加的池中。這就是為什麼答案是true 和false的原因。
3final關鍵字
還是來看一段代碼
[java] view plain
public void mRun(final String name){
new Runnable() {
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(name);
}
}.start();
}
這種代碼相信大家寫過很多，當內部類訪問局部變數的時候，需要在局部變數前加final修飾符，不然編譯器就會報錯。通常我們也是這么乾的。好的，第二個問題來了，為什麼要加final修飾符？相信大多數小夥伴都沒有思考過這個問題，但凡使用的時候，直接加上就得了，從來沒去深究過其中的原理。這對於一個優秀的程序員來說是不可取，我們不僅要知其然還要知其所以然。
現在我們來分析一下，為什麼要加final關鍵字。首先內部類的生命周期是成員級別的，而局部變數的生命周期實在方法體之類。也就是說會出現這樣一種情況，當mRun方法執行，new 的線程運行，新線程裡面會睡一秒。主線程會繼續執行，mRun執行完畢，name屬性生命周期結束。1秒之後，Syetem.out.printh(name)執行。然而此時name已經壽終正寢，不在內存中了。Java就是為了杜絕這種錯誤，嚴格要求內部類中方位局部變數，必須使用final關鍵字修飾。局部變數被final修飾之後，此時會在內存中保有一份局部變得的復製品，當內部類訪問的時候其實訪問的是這個復製品。這就好像是把局部變數的生命周期變長了。說到底還是Java工程師提前把這個坑給我們填了，不然不知道又會有多少小夥伴會為了內部類局部變數而發愁了。
4Integer與int那些事
看下面代碼
[java] view plain
Integer a = new Integer(1000);
int b = 1000;
Integer c = new Integer(10);
Integer d = new Integer(10);
System.out.println(a == b);
System.out.println(c == d);
這道題是繼第一題的後續，如果這道題你能很快速的得出答案，那麼恭喜你，==比較符你就算掌握的比較透徹了。
---------------我是華麗分割線-------------
正確答案： true 、false
看到這個答案很多小夥伴又會不解，先來說下第二個，按第一題來說Integer不是把-128-127緩存起來了嗎？這不是應該是true嘛，但是你仔細看，這里的Integer是我們自己new出來的，並不是用的緩存，所以結果是false。 現在來看第一個為啥又是true了呢？ 首先這里的值為1000，肯定和我們所知的Integer緩存沒有關系。既然和緩存沒有關系，a是新new出來的對象，按理說輸入應該是false才對。但是注意b這里是int類型。當int和Integer進行==比較的時候，Java會把Integer進行自動拆箱，也就是把Integer轉成int類型，所以這里進行比較的是int類型的值，所以結果即為true。
學習Java的同學注意了！！！
學習過程中遇到什麼問題或者想獲取學習資源的話，歡迎加入Java學習交流群，群號碼：232300090【長按復制】 我們一起學Java！
Ⅱ Java 的Integer，int與new Integer到底怎麼回事
1. int 和Integer在進行比較的時候，Integer會進行拆箱，轉為int值與int進行比較。
2. Integer與Integer比較的時候，由於直接賦值的時候會進行自動的裝箱，那麼這里就需要注意兩個問題，一個是-128<= x<=127的整數，將會直接緩存在IntegerCache中，那麼當賦值在這個區間的時候，不會創建新的Integer對象，而是從緩存中獲取已經創建好的Integer對象。二：當大於這個范圍的時候，直接new Integer來創建Integer對象。
3. new Integer(1) 和Integer a = 1不同，前者會創建對象，存儲在堆中，而後者因為在-128到127的范圍內，不會創建新的對象，而是從IntegerCache中獲取的。那麼Integer a = 128, 大於該范圍的話才會直接通過new Integer（128）創建對象，進行裝箱。
Ⅲ java中int變數邊界值問題
你好，很高興回答你的問題。
你的這個是相等的啊。
如果是
Integer a = 128;
Integer b = 128;
他倆是不相等的。
因為java的Integer類在自動裝箱時如果值在-128到127這個范圍內則使用緩存內的對象，這樣相同值就是相同對象。
如果值不在這個范圍，則是新創建對象，即便是相同值也是不同對象。
而等號比較的是是否為相同對象。
如果有幫助到你，請點擊採納。
Ⅳ Integer中的問題
……LZ很有意思。
System.out,println(a=b);
這一句話中有兩個bug,應該是
System.out.println(a==b);
另外這個問題確實是這樣的，Integer會自動緩存[-128,127]之間的Integer對象。不過你如果這么寫：
Integer a = new Integer(126);
Integer b = new Integer(126);
System.out.println(a==b);
輸出false
Ⅳ JAVAEE裡面都包含什麼
Java EE 5是不是象Sun說的是Java EE史上最簡單的版本，它將大大降低開發難度呢？Java EE 5面世後，企業該如何選擇呢？以前使用J2EE1.4及以前版本的企業會升級到Java EE 5嗎？
Java今年已經11歲了。在這11年裡，被應用到了企業、桌面、Web、移動等各個領域。其中覆蓋面最廣的J2EE及相關產品被廣泛應用到企業中。但從1999年誕生的第一個J2EE版本一直到 J2EE1.4總被人們不斷地抱怨，這並不是因為它不夠強大，恰恰相反，正是因為它太強大了，強大得讓人難以使用。
Sun這些年也一直在試圖改變這一切，但一直未能如願。在2002年J2EE1.4推出後，它的復雜程度達到了頂點。尤其是EJB2.0，開發和調試的難度非常大。也許是Sun要下決心改變這一切，或者是受到市場和開發人員的壓力，終於在今年5月份正式發布了J2EE5(現已經改名為Java EE 5)規范，並宣稱Java EE 5將是Java EE史上最簡單的版本，它將大大降低開發難度。但業界對此卻表示懷疑。Java EE 5真的變簡單了嗎？這好像有點突然！Java EE在未來是否能走上一條簡單的光明之路呢？
Java EE 5橫空出世
Java EE 5終於在千呼萬喚中誕生了。在今年的JavaOne會議上，Sun特意派去了一個宣講團，對Java EE 5進行了大吹特吹，並稱Java EE 5最大的改變就是簡化開發。同時，還特別提到了EJB3.0可以通過Java最新提供的注釋（annotations）以及其它一些特性來提高開發和測試的效率。Sun的鼓吹聲還沒有完全散盡，業界的噓噓聲就此起彼伏。一位高級分析師，Richard Monson-Haefel，稱Java EE 5雖然做了很多改進，但仍然無法克服它的龐大和復雜。這位高級分析師目前是EJB3.0規范的設計者之一，從Java EE 5的設計者口中說出這樣的話，我想它的分量一定不輕。
也許Sun並不願意聽到這樣的評論。但Monson-Haefel還是喋喋不休地數落著Java EE 5的種種不是。
Monson-Haefel說：「Java EE中的功能高度集成，我們將無法單獨使用其中的一部分。而且許多Servlet、Java資料庫和JavaServer Pages開發人員一般只使用Java EE的某些相關的特性。但Java EE規范要求必須使用所有的特性[APIs]。為了使程序可以正常運行，這些開發人員不得不建立一個復雜的工程來滿足這些要求。這是因為Java EE仍然保持了上世紀90年代後期的編程方法，也就是說Java EE是以API為中心的」。Monson-Haefel甚至危言聳聽地稱「Java EE的應用已經走到了盡頭！」。
也並不是所有的人都象Monson-Haefel這么悲觀。一位JBoss公司的發言人說：「我們並不完全反對Burton集團高級分析師 Richard Monson-Haefel的關於平台復雜性的觀點，但是沒有人同意他關於Java EE的應用已經走到盡頭的這個結論。」
IBM一向是Java的忠實支持者，也站出來為Java EE說話。Jim Knudson，作為IBM 的Java EE架構師，曾公開表示「雖然Java EE平台在使用上是有一些復雜，但這並不能成為我們放棄這個平台的理由」。
Java EE 5剛一問世，就引來了這么多的議論，當然，這些議論有好的，也有對Java EE 5不利的。那麼Java EE的主要用戶群：企業，該如何做出選擇呢？
企業會為Java EE 5埋單嗎？
Java EE 5面世後，企業該如何選擇呢？以前使用J2EE1.4及以前版本的企業會升級到Java EE 5嗎？
也許Monson-Haefel的一席話會嚇倒很多企業。但Jim Knudson對此仍然很樂觀。雖然他表示同意Java EE平台很復雜這一觀點，但是他說某些復雜性是來自於用戶的需求，並且我們要使用戶達到他們期望的效果。他說IBM的那些預期實現SOA的用戶都打算在 Java EE 5平台上面構建SOA。
JBoss產品管理部主管Ram Venkataraman也支持這樣的觀點：Java EE平台增加了復雜性是有必要的，因為需要使用它來處理各種服務，不僅僅是簡單的調用關系資料庫的Ajax風格Web服務，而且還有大容量事務處理的財務服務。
也許很多企業的負責人聽了這些對Java EE 5贊揚的話，他們會迫不急待地嘗試一下Java EE 5。這對於那些已經或即將搭建SOA構架的企業尤其重要。由於基於Java的SOA一般都是建立在J2EE伺服器上，這就迫使企業必須做出是否升級到新版 Java EE的選擇。
如果企業選擇了Java EE 5，那可能會增加後續的成本。這是因為Java EE 5是基於Sun最新的JDK的，因此，Java EE 5增加了很多新的API。雖然這些API好象使Java EE 5變得更簡單了，但開發人員必須要學習一整套新的編程模型持久化的API。而這些企業必須為此增加培訓的費用。
其實Sun的初衷也是好的，只是簡化Java EE的做法不妥。也許Sun還不明白，一味地增加功能並不能有效地簡化Java EE的使用難度，有時還可能適得其反。如果Sun能夠加一個用於開發的所見即所得（WYSIWYG）的拖放系統，那才叫真正地簡化開發。而象這樣增加很多的API，甚至將編程的思維方式都改變了，這樣做並不能使Java EE平台變得更簡單，而只是換湯不換葯而已。
自從Sun將Java EE平台的設計移交給JCP後，對於Java EE逐漸增加的復雜性，JCP也難辭其咎。作為JCP的成員，Monson-Haefel和JCP的所有成員應該為Java EE 5變成今天這個樣子而負責。實際上JCP的成員很早就和Sun的Java EE 5開發團隊討論過這個問題，但Sun表現得並不積極。這樣看來，JCP和Sun都應該為此負一定的責任。
JCP的主管，Onno Kluyt卻有不同的看法：「Monson-Haefel所看到的復雜性問題並不是JCP所負責的范圍。JCP是一個制定標準的組織，並不是一個負責優化的組織，並不應該為Java EE 5的復雜性負責」。同時Kluyt還提到讓Java EE 5變得更簡單最好方法就是有一個好的IDE，簡單是每個JSR所關注的，也是它們的中心任務。然而Java EE的開發者並不知道怎麼去做。畢竟，Java EE是否簡單，它的開發人員並沒有發言權，而最有發言權的是那些使用Java EE的人。」
Java EE：路在何方
也許上面的喋喋不休使我們的頭都大了，但我們可以不必管它。最後還得讓Sun來蓋棺定論。終於，Sun公司負責企業Java平台的副總裁Karen Padir為Java EE 5作了比較中庸的闡述：「平台當然要復雜了，因為它是應用伺服器的規范。而且，應用伺服器是很復雜的，因為復雜性的存在主要是為了開發人員能夠在應用伺服器上工作，但是應用程序的開發人員並不一定會涉及到復雜性，因為他們僅僅使用那些完成工作所必需的工具就可以了。開發人員可以忽略他們所不需要的復雜性」。
就象微軟的Office一樣，雖然復雜，但並不是所有的人都會涉及到所有復雜的功能。因此，Java EE並沒有我們想像的那樣復雜。反而通過JDK5的支持，在某些應用的性能上，如Web Services，會有很大的提高。因此，如果企業要建立新的應用（尤其是SOA），還是可以考慮Java EE 5的。對於那些已經使用多年的系統來說，升級時得要慎重一些。不過，從總體來說，Java EE 5還是非常不錯的。
Ⅵ java swap（Integer a ,Integer b）實現交換
public class App {
public static void main(String[] args) {
Integer a=1, b=2;
System.out.println("before:a=" + a + ", b=" + b);
swap(a,b);
System.out.println("after:a=" + a + ", b=" + b);
}
public static void swap(Integer i1, Integer i2) {
Integer tmp = i1;
i1 = i2;
i2 = tmp;
}
}
輸出結果：a=1,b=2
java里兩種參數傳遞形式：值傳遞，引用傳遞
java變數分為基本類型，引用類型，兩種類型的參數傳遞給方法時都是按值傳遞
形參和實參所佔的內存地址不一樣
形參中的內容只是實參中存儲的對象引用的一份拷貝
交換的是兩個引用變數的副本，原來的a,b引用指向不變。
請查看Integer.java
private final int value;
public Integer(int value) {
this.value = value;
}
public class App {
public static void main(String[] args) {
Integer a=1; // Integer a = Integer.valueOf(1); IntegerCache.cache[1+128] == 1
Integer b=2;
System.out.println("before: a=" + a + ", b=" + b);
swap(a, b);
System.out.println("after: a=" + a +", b=" + b);
}
public static void swap(Integer i1, Integer i2) throws NoSuchFieldException {
//通過反射獲得類私有不可變變數（private final int value;）
Field field = Integer.class.getDeclaredField(name:"value");
//通過setAccessible去訪問私有的成員變數
field.setAccessible(true);
int tmp = i1.intValue(); //tmp值是1，
field.set(i1, i2.intValue()); // i1的值設置為Integer.valueOf(i2.intValue()).intValue()，此時i1地址是IntegerCache.cache[1+128]: 值為2
field.set(i2, tmp); //int-->Object Integer.valueOf(tmp).intValue(), tmp的值是地址IntegerCache.cache[1+128],
}
｝
javap -v App.class 查看App的位元組碼
自動封裝
Integer a = 1; // Integer a = Ineger.valueOf(1);
valueOf(int i) i在-128到127之間，返回緩存中的值 return IntegerCache.cache[i + (-IntegerCache.low)]
所以Integer a=1，b=1時，a == b ，兩個的內存地址是同一個。
上面運行結果：
a=2, b=2
解決：
Integer tmp = new Integer(i1.intValue());
得 a=2, b=1
知識點：
1.自動裝箱和拆箱
2.Integer -128到127之間的緩存
3.反射，通過反射去修改private final 變數。
https://www.cnblogs.com/doStudying/p/7851254.html 這里列出了field.setInt()方法，跟上面的set方法的區別， 應該？是參數類型不一致，是否用到IntegerCache
http://www.docin.com/p-700305321.html 這里副本的值指向a,b的地址。用this可實現，但注意static方法里不能用this。
Ⅶ JAVA中 為什麼這三種輸出結果是true,false,true
int 是基礎數據類型， Integer 是類, 是對 int的封裝對象，具備對象的一切特性。
Integer是一個對象，==比較的是引用地址，與 int 比較，jvm會將Integer轉化為int, 所以結果為true。
但Integer之間比較時，如果是用new創建的對象，一定返回false。
Integer 大於127 是需要新建 new 對象。Integer c = 128 ;會編譯為 Integer c = Integer.valueOf(128); 是用new創建的對象。Integer d = 128; 也是用new創建，所以返回false。
Ⅷ java中Integer在JDK1.6和JDK1.7中的區別
運行下面這段代碼：
System.out.println(Integer.valueOf("127")==Integer.valueOf("127"));
System.out.println(Integer.valueOf("128")==Integer.valueOf("128"));
System.out.println(Integer.parseInt("128")==Integer.valueOf("128"));
JDK1.6輸出結果：
false
false
true
JDk1.7輸出結果：
true
false
true
JDK1.7版本開始，Integer有了靜態緩存，這點注意一下。
Ⅸ java stringbuffer 的緩沖長度多少
StringBuffer緩沖長度，或者叫容量會隨著內部儲存的字元串長度而翻倍增大。
比如用了49個字元，容量為50，再加入2個字元時，容量會從50變成100，此時字元串長度為51
初始容量默認為16，也可以自定義更小或更大。
Ⅹ java里Integer類在-128和127之間為什麼能直接用==比較,好像還只能在自動裝箱的時候是嗎求詳解，謝謝啦！
因為Integer實現的時候 對於-128 到127之間的值會做緩存處理
比如 Integer i=100,j=100;
那麼j實際上就是指向的i,因為i緩存了
如果Integer i=200,j=200;
這時候不會緩存，會新建一個對象200,
所以第一次 i==j為真
第二次 i==j為假