成长

我与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最中年危机说到底还是个人技术已经跟不上节奏了，而保持节奏的最佳手段就是保持学习，不仅要学习书本上的理论，还要学习技术是如何落地的。

此外，下半年我将尝试一下新专栏的创作，相关准备工作已经在进行中了，仍然免费，希望各位同学看了我的文章之后能有所收获，大家努力~