每個月IT摘錄201812

技術

1.JVM、Java併發、NIO、網絡通訊，這些都是一個java工程師必須具有底層技術素養。
2.關於技術廣度。消息中間件、分佈式緩存、海量數據、分佈式搜索、NoSQL、分佈式架構、高併發、高可用、高性能，這些技術，並非說真的要求工做幾年的同窗每一個技術都精通到源碼層面，而是說你工做幾年之後，應該有必定的技術廣度，開闊的技術視野。各類技術你都得適當的瞭解一些，同時儘量有機會的話在本身負責的項目裏多實踐各類技術，多體會各類技術如何組成出一套架構來解決公司的技術難題的，儘可能多對各類技術都必定的實踐經驗。
3.技術深度的考察是中大型互聯網公司面試官對一個高級/資深以上的候選人必須考察的，由於若是一我的工做5年以上，來應聘高級職位的話，那咱們絕對是要求他對至少一個技術領域有着較爲深刻的研究的，好比提及碼你得深刻閱讀過某個熱門技術的核心源碼，有必定的技術功底，能夠解決一些複雜的線上故障。由於技術廣度決定了你能夠利用各類技術來作項目，可是技術深度決定了你的技術功底，你將來學新東西有多快，線上系統出了故障你可否快速定位和解決，你可否基於對技術的深入理解爲公司的項目設計和開發出複雜並且優秀的架構出來。
4.如今一些中大型互聯網公司的面試官，不少都是技術水平很是不錯的兄弟。在面試候選人的時候，通常都會採起連環炮的策略來深挖一個候選人的技術水平。
說說大家公司線上生產環境用的是什麼消息中間件？
那大家線上系統是有哪些技術挑戰，爲何必需要在系統裏引入消息中間件？
大家的消息中間件技術選型爲何是Kafka？爲何不用RocketMQ或者是RabbitMQ？技術選型的依據是什麼？
大家用的是Kafka？那你說說Kafka的底層架構原理，磁盤上數據如何存儲的，總體分佈式架構是如何實現的，如何保證數據的高容錯性，零拷貝等技術是如何運用的，高吞吐量下如何優化生產者和消費者的性能？那你看過Kafka的源碼沒有，說說你對Kafka源碼的理解？
若是讓你來動手實現一個分佈式消息中間件，總體架構你會如何設計實現？
5.紅黑樹，是一種二叉查找樹。節點標記爲紅色或黑色，根節點必須是黑色，規律是「有紅必有黑，紅紅不相連」
6.強迫本身在代碼開發前，多畫一些架構圖、數據流程圖，寫代碼的時候也強迫本身代碼分層，通過半年的磨鍊，漸漸的也能寫出一些鬆耦合高內聚的代碼，也改變了滿屏if-else亂飛的現象。
7.容器技術：docker是容器。 Kubernetes(k8s)是Google開源的容器集羣管理系統
8.FutureTask 是一個支持取消的異步處理器，通常在線程池中用於異步接受callable返回值。
主要實現分三部分：
封裝 Callable，而後放到線程池中去異步執行->run。
獲取結果-> get。
取消任務-> cancel。
9.OSGi(Open Service Gateway Initiative)技術是Java動態化模塊化系統的一系列規範。
10.應用層的知識都是次要的，學到的編程能力和編程思惟纔是最重要的，畢竟一門通，門門通。何況對於程序員來講，編程能力和編程思惟佔了 80%，其餘 api 的運用只佔了 20%
11.Rpc和RestFul的比較：
RPC的思想是把本地函數映射到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠程也能經過某種約定的協議來調用這個getAllUsers。至於這個協議是Socket、是HTTP仍是別的什麼並不重要； RPC中的主體都是動做，是個動詞，表示我要作什麼。
而REST則否則，它的URL主體是資源，是個名詞。並且也僅支持HTTP協議，規定了使用HTTP Method表達本次要作的動做，類型通常也不超過那四五種。這些動做表達了對資源僅有的幾種轉化方式。
12.技術必須和業務情景結合，才能更好地地理解。
13.不管是RocketMQ、Kafka仍是RabbitMQ，都有相似的autoAck或者是手動ack的機制。線上生產環境中運行時，你必需要考慮到消費者服務可能宕機的問題。若是消費者服務沒處理完消息就本身宕機了，那麼必定會致使部分消息的丟失，進而影響核心業務流程的運轉。
14.秒殺通常用redis。若是不想用nosql，非要用數據庫，就得加一個version字段。(除了設置version解決，也能夠用使用狀態表示來解決)
（1）首先是程序讀取select version, left from table;
（2）而後記錄version字段（舊值），斷定left - buyCount(購買數量)>=0，若是否退出，結束業務。不然繼續（3）
（3）開始執行減庫存
update table set left = left - #{byCount} , version = version+1
where count >0 and vesion = #{vesion}//這個version是舊值，而更新一次成功version就加1
這裏數據庫並無任何鎖，可是這裏巧妙的使用了version字段，符合一個CAS原理，就是我當初讀出的version（舊值）和實時數據庫的version（當前須要更新時刻的實時值）是否一致，若是一致，則我會認爲這條記錄沒有被其餘線程修改，則減庫存成功，若是不一致則我會認爲其餘線程修改過這個記錄。就不會進行操做這個被稱爲樂觀鎖。這個時候咱們會考慮重入，重複執行（1）-（3）步驟直至（2）的退出或者（3）成功繼續咱們的操做，這樣就是一個沒有鎖的機制。這就是一個樂觀鎖的機制，而沒有任何等待的機制，是一個非阻塞的過程。
最好使用redis去完成秒殺的話。redis提供的事務很好的符合了秒殺的功能。
首先任何線程執行redis的操做的時候都是使用lua語言，redis在執行lua語言的時候是原子性的，讓它執行減庫存，而且記錄用戶購買記錄。
直至秒殺時間到期或者庫存爲0，才考慮將redis緩存的數據批量一次性把減庫存和用戶購買的信息批量寫入mysql。整個秒殺過程基本在redis完成，而不是數據庫，不是mysql的性能可比的，服務器上mysql一秒能夠4萬次，redis能夠上百萬次
15.在zookeeper中，leader主要負責讀寫，follower 負責同步，只負責備份。
16.ACK (Acknowledgement）便是確認字符，在數據通訊中，接收站發給發送站的一種傳輸類控制字符。 表示發來的數據已確認接收無誤。 在TCP/IP協議中，若是接收方成功的接收到數據，那麼會回覆一個ACK數據。在消息隊列中也存在ACK機制。
17.併發中的經常使用操做：

(1) 若是一個對象的成員變量有一個線程對它進行寫操做，即set賦值。多個線程對它進行讀操做，即get取值。就用volatile輕量級鎖關鍵字修飾。

(2) 若是是多寫多讀，就請在get set方法加synchronize關鍵字加鎖，或者用併發包下的Lock包下的顯示鎖加鎖。

(3) 加鎖有個缺點，每次getset都讓你的線程多一步獲取鎖的操做。若是你不想對這個成員變量的讀寫方法加鎖又要保證線程安全就請用Atomic包下的原子變量定義這個成員變量，它是用CAS無鎖算法實現的。ConcurruntHashMap就用了它。
(4)若是你既想定義成員變量又不但願它共享給多個線程從而帶來併發問題，你就用ThreadLocal定義這個成員變量，它是每一個線程獨立使用，各自不可見的。

學習

1.堅持刻意學習。不斷反饋糾錯。自我測試。主動學習。跳出溫馨區。多複習增強記憶。
2.項目驅動的學習方法：學習一段時間，作個小項目，將作項目遇到的問題記下來，針對性地學習相關知識，而後再實踐，再學一段時間理論，讓知識成網狀發射狀地變大。固然，項目驅動式學習有一個弊端，就是每次學習的知識都是項目所須要的，很零碎、不成體系，因此須要改良，即在採起項目驅動學習法的時候天天抽一段時間去完整地讀一本書，或者一個相關問題的完整介紹，這樣就很容易把一些知識成體系地串起來。這樣一段時間下來，慢慢的，你就知道咱們爲何要學那麼多科目，學這些科目能幹什麼。
3.有些人最愛問的一句話就是，你學成這樣學了多長時間？你們好像都在暗中較勁兒，他花了多少天學完了什麼什麼，我就應該比他更快，由於沒幾我的願意認可本身比別人笨。我以爲這種比較是毫無心義的，由於每一個人的基礎、時間、資源、天賦、環境都不同，每一個人學到的深度也不同，怎麼比？越比越焦躁
4.若是你想作好一件事，那就天天去作。包括聖誕節，復活節和審判日。沒有例外。
5.實施細節並非知識，而是操做步驟。若是技術棧發生變動，實施細節就會毫無用處。可是，你又不能不學習它，不知道實施細節，就無法作出項目。我以爲，程序員應該要警戒，不要落入實施細節的陷阱，不要把所有精力花在實施細節上面，而後覺得本身學到了真正的知識。對待各類語言和工具，正確的態度應該是「進得去，出得來」，既要了解足夠的細節，也要可以站在宏觀的角度看待它，探尋底層究竟是怎麼實現的。

工做

1.公司要拋棄你時，可能你上午還在幹活，下午就得滾蛋了。只有不斷地提升競爭力，纔不會被淘汰。
2.關於項目經驗。介紹產品時面試官會考察應聘者的溝通能力和思考能力，咱們大部分狀況都是作產品的一個功能或一個模塊，可是即便是這樣，本身有沒有把整個系統架構或產品弄清楚，並能介紹清楚，爲何作這個系統？這個系統的價值是什麼？這個系統有哪些功能？優缺點有哪些？若是讓你從新設計這個系統你會如何設計？
3.跳出溫馨圈，找到目標是前進的起點。若是你在本身當下的工做中沒法接觸太多的新技術，能夠嘗試多去外面公司面試，這能在必定程度上幫助本身找到學習的目標；
跳槽要趁早，杜絕成爲溫水裏的青蛙。對於想跳槽到大公司的同窗來講，必定要趁早。由於一樣的水平狀況下，大公司更會看中「潛力」—— 年齡越大，潛力越小；
始終保持你的學習欲。對於工程師來講，學習永無止境。但埋頭苦學是不夠的，你要注意本身的學習必定要有系統性，除了手頭的項目和身邊「大牛」的指導外，看書和網絡課程是最有效的方法，用少許的金錢換取寶貴的時間，是很是值得的。
若是你依然以爲有些茫然，不如跟有多年Java開發經驗的資深工程師聊一聊。
4.若是你是個寫Java的，我不只想知道你會不會寫Java，我還想知道你是怎麼寫的，在什麼樣的平臺上?運用了哪些框架?相關配套技術有哪些?數據庫有哪些?到底寫了個什麼東西?爲誰寫的?是給公司內部使用仍是作甲方的項目?是負責架構設計仍是模塊開發仍是後期的bug調試?除了Java還會別的麼?我對你瞭解地越多，我就越能判斷出你是否是適合應聘的職位，這對咱們後期的溝通就越有效。
5.你作過什麼樣的項目?給哪家公司作的?多大的體量?最終使用人羣是多少?
你在項目中的角色是什麼?是參與者仍是組織者仍是負責人?是負責前期客戶需求溝通仍是後期項目交付?達到了什麼樣的結果?客戶對你的評價是什麼?有提早完成項目的經歷麼?
這個項目給你帶來的經驗是什麼?是否可以積累必定的行業資源?這只是咱們從一個項目中就能分析出來的信息。
而多個項目組合起來來看，咱們就能清晰地感知到候選人的主要客戶主要base在哪些行業或是領域?都是什麼樣級別的客戶?而他對話的人在甲方又是什麼樣level的?
6.將簡歷名稱命名爲「應聘職位-姓名-畢業學校-現處公司-工做年限」
7.簡歷項目經驗：「我參與了手機XX網發佈系統WAPCMS的開發（這部分是你們都會寫的）。做爲核心程序員，我不但完成了網站界面、調度隊列的開發工做，更提出了高效的組件級緩存系統，經過碎片化緩衝有效的提高了系統的渲染效率。（這部分是不少同窗忘掉的，要寫出你在這個項目中具體負責的部分，以及你貢獻出來的價值。）在該系統上線後，Web前端性能從10QPS提高到200QPS，服務器由10臺減小到3臺（經過量化的數字來加強可信度）。2008年我升任WAPCMS項目負責人，帶領一個3人小組支持着天天超過2億的PV（這就是Benefit。你能帶給前僱主的價值，也就是你能帶給新僱主的價值。）」
有同窗問，若是我在項目裏邊沒有那麼顯赫的成績能夠說怎麼辦？講不出成績時，就講你的成長。由於學習能力也是每家公司都看中的東西。你能夠寫你在這個項目裏邊遇到了一個什麼樣的問題，別人怎麼解決的，你怎麼解決的，你的方案好在什麼地方，最終這個方案的效果如何。
具體、量化、有說服力，是技術簡歷特別須要注重的地方。
8.簡歷項目經驗：我在此項目負責了哪些工做，分別在哪些地方作得出色/和別人不同/成長快，這個項目中，我最困難的問題是什麼，我採起了什麼措施，最後結果如何。這個項目中，我最自豪的技術細節是什麼，爲何，實施前和實施後的數據對好比何，同事和領導對此的反應如何。

生活

1.「用出世的精神作入世的事業」--朱光潛。

其餘

1. 幾千年來一切都在改變，但惟有人性沒有變。把握了人性，瞭解了人性的慾望和弱點，掌握了人性的貪婪、嫉妒、驕傲、好逸惡勞，你就掌握了打開人心的鑰匙，你就掌握了智慧。