2015年進步很小,看的書也不是不少,感受本身都要廢了,2016是沉澱的一年,在這一年中要不斷學習、看書,努力提高本身!預計在2016年要看12本書,主要涉及java基礎、Spring研究、java併發、JVM、分佈式之類的。在今年面試的時候深受打擊,處處都是問分佈式、集羣的?難道如今工做兩三年的都這麼牛逼了?都在搞分佈式、集羣之類的?java
2016書單以下:mysql
一、深刻理解Java虛擬機:JVM高級特性與最佳實踐---(已看,預計今年看三遍)面試
二、Oracle查詢優化改寫技巧與案例---(已看)sql
三、Effective Java---(已看)編程
四、Spring3.x企業應用開發實戰數組
五、Spring技術內幕:深刻解析Spring架構與設計原理---(這本書在去年已經看了一遍了,今年在好好研究下)緩存
六、Java併發編程的藝術安全
七、Java併發編程實戰---(這本書在去年已經看了一遍了,今年在好好研究下)架構
八、型網站系統與Java中間件實踐併發
九、分佈式服務框架原理與實踐
十、大型分佈式網站架構設計與實踐
十一、從Paxos到Zookeeper分佈式一致性原理與實踐
十二、高性能mysql
目前已經看完了三本書:深刻理解Java虛擬機:JVM高級特性與最佳實踐、Oracle查詢優化改寫技巧與案例、Effective Java。其中深刻理解jvm這本書確實是一本神書,看完以後真的有種豁然開朗的感受,期待三遍以後給我醍醐灌頂的感受。Oracle查詢優化,感受通常般。Effective java,四大聖經之一不作解釋。
各位,有什麼好書,麻煩推薦下,LZ不勝感激!
LZ沒看一本書,都會作一些筆記,固然這些僅僅只是筆記而已!剛剛開始有點兒簡陋,不要介意,若是對你還有點兒幫助,LZ一心滿意足了!
1.2.用私有構造器或者枚舉類型強化Singleton屬性
1.4.經過私有構造器強化不可實例化的能力。
1.5.避免建立沒必要要的對象。
優先使用基本類型而不是裝箱基本類型,要小心無心識的自動裝箱。
1.6.消除過時的對象引用
若是一個棧先是增加,再是收縮,那麼,從棧中彈出來的對象將不會被當作垃圾回收,即便使用棧的程序再也不引用這些對象,他們也不會被回收。這是由於,棧內部維護這對這些對象的過時引用。所謂過時引用則是指永遠也不會再被解除的引用。
通常來講,對於過時引用咱們都是清空這些引用便可(也就是set null),可是這樣勢必會致使程序變得異常混亂,最好的辦法則是讓包含該引用的變量結束生命週期。
出現內存溢出常見的來源有:一、過時引用,二、緩存,三、監聽器和其餘回調。對於緩存咱們一般的作法則是定時地清除一些沒有用的項,想一想緩存裏面保存了幾年了無用的項是否是都以爲噁心?回調則是隻保存他們的弱引用,例如只將他們保存成WeakHashMap的鍵。
能夠藉助Heap剖析工具分析內存泄漏的問題
良好的模塊設計能夠將全部的實現細節隱藏,把他的API與具體的實現清晰地隔離開來,模塊與模塊之間只經過他們的API進行通訊,一個模塊不須要知道其餘模塊的內部工做狀況---信息隱藏。
1)爲了使類不可變,須要遵循以下規則:
1.不要提供任何會修改對象狀態的方法
2.保證類不會被擴展
3.全部域都要是final,且爲私有
4.確保對於任何可變組件的互斥訪問。
2)不可變類的好處
1.不可變對象本質是線程安全的,不要求同步
2.不可變對象爲其餘對象提供了大量的構件
3)缺點在於須要爲每個不一樣的值提供不一樣的對象。若是建立的對象比較大,那麼所產生的代價就有點高了。
爲了避免可變性,類是絕對不容許被子類化,咱們首先想到的就是「final」修飾,其實除了這點還有一個比較好的辦法:讓類的全部構造器所有變爲私有,而且提供一個公有的靜態工廠。
優先使用組合,慎用繼承。
組 合 關 系 | 繼 承 關 系 |
優勢:不破壞封裝,總體類與局部類之間鬆耦合,彼此相對獨立 | 缺點:破壞封裝,子類與父類之間緊密耦合,子類依賴於父類的實現,子類缺少獨立性 |
優勢:具備較好的可擴展性 | 缺點:支持擴展,可是每每以增長系統結構的複雜度爲代價 |
優勢:支持動態組合。在運行時,總體對象能夠選擇不一樣類型的局部對象 | 缺點:不支持動態繼承。在運行時,子類沒法選擇不一樣的父類 |
優勢:總體類能夠對局部類進行包裝,封裝局部類的接口,提供新的接口 | 缺點:子類不能改變父類的接口 |
缺點:總體類不能自動得到和局部類一樣的接口 | 優勢:子類能自動繼承父類的接口 |
缺點:建立總體類的對象時,須要建立全部局部類的對象 | 優勢:建立子類的對象時,無須建立父類的對象 |
請記住下面兩句話:
繼承要慎用,其使用場合僅限於你確信使用該技術有效的狀況。一個判斷方法是,問一問本身是否須要重新類向基類進行向上轉型。若是是必須的,則繼承是必要的。反之則應該好好考慮是否須要繼承。《Java編程思想》
只有當子類真正是超類的子類型時,才適合用繼承。換句話說,對於兩個類A和B,只有當二者之間確實存在is-a
關係的時候,類B才應該繼續類A。《Effective Java》
1.接口是定義mixin的理想選擇
2.接口容許咱們構造非層次接口的類型框架
3.骨架實現類
經過對你導出的每個重要接口都提供一個抽象的骨架實現類,把接口和抽象類的優勢結合起來。這個時候接口的做用仍然是定義類型,可是骨架實現類接管了全部域接口實現相關的工做。骨架實現被稱之爲AbstractInterface。
骨架實現的美妙之處在於,它們爲抽象類提供了實現上的幫助,可是又不會強加「抽象類被用作定義類型時」所特有的嚴格限制。同時在編寫骨架實現時通常都須要通過認真研究接口,並肯定那些方法是最爲基礎的,其餘方法則能夠根據他們來實現。這些基本的方法將成爲骨架實現類中的抽象方法(這裏是模板方法模式??)。
4.接口只用於定義類型。
5.常量接口不值得效仿,接口應該只被用來定義類型,不該該被用來導出常量。
6.對於常量的使用咱們應該遵循以下規則:若是常量與某個現有的類或者接口緊密相關,就應該把這些常量添加到這個類或者接口中;若是常量最好被看作枚舉類型的成員,則應該用枚舉類型來導出這些常量;不然應該使用不可實例化的工具類來導出這些常量。
內部類的主要做用應該只爲他的外圍類提供服務。內部類主要有四種:靜態成員類、非靜態成員類、匿名類、局部類。
靜態成員類經常使用做爲公有的輔助類,僅當與它的外部類一塊兒使用時纔有意義。私有靜態成員類一種經常使用的方法是用來表明外圍類所表明的對象的組件,他它不須要依賴外圍類。
匿名內部類沒有名稱,它並非外圍類的一個成員,它並不與其餘的成員一塊兒被聲明,而是在使用的同時被聲明和實例化。在使用的過程當中,除了在他們被聲明的時候以外,是沒法將他們實例化的。匿名類有三種經常使用的用法:動態建立函數對象,建立過程對象(Runable、Thread、TimeTask)、靜態工廠方法的內部。
推薦使用泛型,雖然他在運行時會被擦除。
儘量地消除每個非受檢警告。若是沒法消除警告,同時能夠證實引發警告的代碼是類型安全的,則可使用@SuppressWarnings("unchecked")註解來禁止這條警告,同時咱們必需要竟可能小的範圍使用該註解,禁止在整個類上使用該註解。
7.1必要時,對不可變對象的構造器和訪問方法進行檢查性保護。
1.謹慎地選擇方法的名稱:方法名稱應該始終遵循標準的命名習慣。
2.不要過於追求提供便利的方法,每一個方法應該極盡其所能。
3.避免過長的參數列表,一邊提供四個參數或者更少。
避免參數過長通常有三種方法:1).將該方法分解成多個方法 2).建立輔助類,用來保護參數的分組 3).從對象構建到方法的調用都採用Builder模式。
4.優先使用接口而不是實現類來做爲參數類型。你應該不會把HashMap做爲一個參數的!!
1.方法重載是在編譯時作出決定的。
2.永遠都不要導出兩個具備相同參數數目的重載方法,這是一個安全保守的方法。
3.任何一組給定的實際參數將應用於那個重載方法上。
4.同一組參數只須要通過類型轉換就能夠被傳遞給不一樣的重載方法,若是不能避免這種狀況,就應該保證:當傳遞一樣的參數是,全部重載方法的行爲必須一致。
可變參數接受0個或者多個指定類型的參數。其機制是先建立一個數組,數組的大小爲在調用位置所傳遞參數的數量,而後將參數值傳遞給數組,最後將數組傳遞給方法。
7.五、返回零長度的數組或者集合,而不該該是null。不重要可是值得注意。
將局部變量的做用域最小化,能夠加強代碼的可讀性和可維護性,並下降出錯的可能性。
要是局部變量的做用域最小化,最有力的方法就是在第一次使用它的地方聲明。通常來講每一個局部變量都應該有一個初始化,若是沒有足夠的信息來對該變量進行有意義的初始化,則須要推遲該變量的聲明,直到能夠被初始化爲止。
對於方法而言,應該儘量地使方法小而集中,這樣就能夠將局部變量的做用域儘量地小化。
for循環相比於while循環它可使局部變量更小化,同時程序更加簡短加強了可讀性。
for-each循環在簡潔性和預防bug方面有着傳統for循環沒法比擬的優點,而且沒有性能損失,因此咱們應該儘量使用for-each循環,可是在如下三種狀況是否沒法使用for-each循環的:
1.過濾:若是須要遍歷某個集合,刪除特定的元素,則須要使用顯示的迭代器。
2.轉換:若是須要遍歷列表或者數組,並取代它部分或者所有元素值,這時就須要迭代器來進行設置元素的值。
3.平行迭代
基本類型至關於其引用類型有以下幾個區別:1.)基本類型只有值,而引用類型則具備他們值不一樣的同一性,也就說new Integer(1) != new Integer(1);2).基本類型具備功能完備的值,而引用還有一個null值 3).基本類型一般比引用類型更加節省空間和時間。
當在一項操做中混合使用基本類型和其引用類型時,其引用類型會自動進行拆箱動做。
在進行迭代時須要格外注意拆箱裝箱機制,由於頻繁的拆箱裝箱會致使性能的降低。
其餘
1.若是須要精確的答案,請使用BigDecimal而不是double和float。
2.若是有合適的接口類型存在,那麼對於參數、返回值、變量和域來講,就都應該使用接口類型進行聲明。
異常應該只用於異常的狀況下,他們永遠不該該用於正常的控制流。
異常機制設計是用於不正常的狀況,因此不多會有JVM會對他進行優化,因此異常通常運行都比較慢。
咱們應該儘可能讓異常代碼塊小,由於try..catch會阻礙JVM實現原本可能要執行的某些特定的優化。