在寫(xiě)代碼的過(guò)程中，我們很容易忽略一些問(wèn)題，針對(duì)這些問(wèn)題小編匯總了以下幾點(diǎn)，希望可以幫助到大家：

　　糾結(jié)的同名

　　現(xiàn)象

　　很多類(lèi)的命名相同（例如：常見(jiàn)于異常、常量、日志等類(lèi)），導(dǎo)致在import時(shí)，有時(shí)候張冠李戴，這種錯(cuò)誤有時(shí)候很隱蔽。因?yàn)橥念?lèi)功能也類(lèi)似，所以IDE不會(huì)提示warn。

　　解決

　　寫(xiě)完代碼時(shí)，掃視下import部分，看看有沒(méi)有不熟悉的。替換成正確導(dǎo)入后，要注意下注釋是否也作相應(yīng)修改。

　　啟示

　　命名盡量避開(kāi)重復(fù)名，特別要避開(kāi)與JDK中的類(lèi)重名，否則容易導(dǎo)入錯(cuò)，同時(shí)存在大量重名類(lèi)，在查找時(shí)，也需要更多的辨別時(shí)間。

　　不要影響彼此

　　現(xiàn)象

　　在釋放多個(gè)IO資源時(shí)，都會(huì)拋出IOException，于是可能為了省事如此寫(xiě)：

publicstaticvoidinputToOutput(InputStreamis,OutputStreamos,booleanisClose)throwsIOException{BufferedInputStreambis=newBufferedInputStream(is,1024);BufferedOutputStreambos=newBufferedOutputStream(os,1024);….if(isClose){bos.close;bis.close;}}

　　假設(shè)bos關(guān)閉失敗，bis還能關(guān)閉嗎？當(dāng)然不能！

　　解決辦法

　　雖然拋出的是同一個(gè)異常，但是還是各自捕獲各的為好。否則第一個(gè)失敗，后一個(gè)面就沒(méi)有機(jī)會(huì)去釋放資源了。

　　啟示

　　代碼/模塊之間可能存在依賴(lài)，要充分識(shí)別對(duì)相互的依賴(lài)。

　　忘設(shè)初始容量

　　現(xiàn)象

　　在JAVA中，我們常用Collection中的Map做Cache,但是我們經(jīng)常會(huì)遺忘設(shè)置初始容量。

　　cache=newLRULinkedHashMap<K,V(maxCapacity);

　　解決

　　初始容量的影響有多大？拿LinkedHashMap來(lái)說(shuō)，初始容量如果不設(shè)置默認(rèn)是16，超過(guò)16×LOAD_FACTOR,會(huì)resize(2*table.length),擴(kuò)大2倍：采用EntrynewTable=newEntry[newCapacity];transfer(newTable)，即整個(gè)數(shù)組Copy，那么對(duì)于一個(gè)需要做大容量CACHE來(lái)說(shuō)，從16變成一個(gè)很大的數(shù)量，需要做多少次數(shù)組復(fù)制可想而知。如果初始容量就設(shè)置很大，自然會(huì)減少resize,不過(guò)可能會(huì)擔(dān)心，初始容量設(shè)置很大時(shí)，沒(méi)有Cache內(nèi)容仍然會(huì)占用過(guò)大體積。其實(shí)可以參考以下表格簡(jiǎn)單計(jì)算下,初始時(shí)還沒(méi)有cache內(nèi)容,每個(gè)對(duì)象僅僅是4字節(jié)引用而已。

　　啟示

　　不僅是map,還有stringBuffer等，都有容量resize的過(guò)程，如果數(shù)據(jù)量很大，就不能忽視初始容量可以考慮設(shè)置下，否則不僅有頻繁的resize還容易浪費(fèi)容量。

　　在Java編程中，除了上面枚舉的一些容易忽視的問(wèn)題，日常實(shí)踐中還存在很多。相信在不斷的實(shí)踐中自己就可以發(fā)現(xiàn)并改正。