文章目錄

• 成長
• 回饋
• 今后創作規劃

成長

我與CSDN初始于2016年，到如今已經是一個六年的老用戶了，從一名學生已經成長為了公司的一名后端開發工程師。

記得那會兒我還是處于學生階段，學校的課程開了一門C++，后來又因為種種原因接觸到了Java的學習，由于初學者的原因，經常會遇到一些奇奇怪怪的bug，也有一些需要安裝的軟件，所以就養成了上網搜索資料的習慣，經常在CSDN平臺的各個帖子里學習知識，修改bug，安裝軟件等等…

后來隨著學業的深入，我接觸到的知識也越來越多了，慢慢的也可以自己發現問題、分析問題、找到問題，并且還會有想要把新知識分享出去的沖動，于是就嘗試開始自己博客的創作，從Java基礎知識，到數據結構與算法，再到后來的各種架構和學習路線的輸出等等，現在回頭看自己發表過的每一篇博客，從技術的稚嫩到不斷的深入，CSDN記錄了我整個Java學習生涯的過程！

稚嫩的初期文章：

初現章法的現期文章：

回饋

小王近幾年的寫作一直秉承著幫助越來越多的同學走進大廠的理念，所以所有文章皆免費，對于文章中出現的各種資源，也無償提供給了粉絲們，包括之前花了最多心思寫的Spring源碼解析系列，糾結了很長一段時間之后還是沒有設置成付費專欄：

https://blog.csdn.net/hnu_csee_wjw/category_10931055.html

當然創作過程是痛苦的，但收獲確是快樂的，每當后臺收到粉絲私信說幫助他解決了什么問題時，這種感覺妙不可言~

今后創作規劃

經常關注我的小伙伴可能發現了，我最近的寫作重點在于輸出一些阿里系常用的技術，不同于CSDN中常見的面試系列，我希望借此機會來幫助大家開闊一下視野，特別是在校生。

在我看來，很多經典Java書籍中的部分理論已經不適用于當今分布式系統了，舉一個之前舉過的例子，Java多線程的線程數應該怎么設置呢？

《Java Concurrency in Practice》中寫到：

對于CPU密集型任務，建議線程數設置為 CPU核心數 + 1

《Programing Concurrency on the JVM》中寫到：

最小線程數 = CPU核心數

對于IO密集型業務，建議線程數設置為CPU核心數 / (1-阻塞系數)，其中

還有一種坊間大神說法是 線程數 = 2*CPU核心數

很殘酷的是，上面的理論放到現在來看，其實都不正確，原因如下：

• 上面兩本書的寫作年代過于久遠，已經不適用于當今的微服務，新的JVM等等

• 上面的公式都過于關注CPU核心數，但實際上當今云技術很多復雜的服務只是跑在2核8G的CPU上，2核8G也是阿里云的標配服務器

• 當今更多采用的是混合部署，IO密集型業務和CPU密集型業務部署在一起，這就導致了上面任何一個公式都不好用

那么什么是正確的做法呢？
實際上，真理還得是從實踐中得到，需要通過測試驗證來得到最終的最佳線程數。測試和驗證是基于性能測試為背景，在這個過程中可以不斷增加和減少線程數

• 當增加線程數時：如果接口每秒處理的請求（QPS）不會再增加了，甚至接口響應時間變長，此時設置的線程數可能已經超過了最佳線程數

• 當減少線程數時：如果接口QPS下降，說明集群性能還有提升的空間

通過上面兩個條件，就可以在測試中壓出最佳線程數（這也是多數淘系應用如今的做法~~）

---

所以在我看來，定時更新自己個人的知識儲備是保證自己競爭力的前提，35最中年危機說到底還是個人技術已經跟不上節奏了，而保持節奏的最佳手段就是保持學習，不僅要學習書本上的理論，還要學習技術是如何落地的。

此外，下半年我將嘗試一下新專欄的創作，相關準備工作已經在進行中了，仍然免費，希望各位同學看了我的文章之后能有所收獲，大家努力~

總結

以上是生活随笔為你收集整理的小王在CSDN的六年创作历程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。