就在我作为软件开发的技术岗位工作了十多年之后，未管理岗位，依然有所收获。也就是说，我亲自体会到了一把技术岗位30岁焦虑可以不存在的事件。
个人成长
对于几乎绝大多数软件开发者，工作所经历的往往就是单纯的CRUD，也可以土一点叫做增删改查。工作十年，经验等同于一年，我庆幸我不是这类人，我的第一个重点投入的项目，就是前东家之一的汽车GPS服务后台。接近7年，从零到一体会到了众多的变化过程，丰富了很多别人看不到的解决问题的视角与发展过程的认知。但是持续的关注在单一领域确实有问题，也庆幸自己当时选择了离职，离职后的这段时间，极大的填补了自己的经历缺陷：
体验了大公司的专岗模式：
入职到一家上市公司做了一次纯后端，更体系化的参与了一个项目，不再像以前的从零到一阶段的全干思想。
体会了超越开发的岗位视角：
在这家上市公司接触到更多的岗位细分人员，结合更专业的管理工具实现了更大团队的配合。终于对专业人做专业事思维有了一次认可。有了适配场景的认识。
体会了市场经济的跌宕：
误打误撞做了阿里云代理商相关支持，技术与销售岗位同时具备。，有过持续的低收入，也有过突然确认的大订单，不再只看固定工资收益。
体会了小幅度切换工作领域的成长：
车联网视角扩大到物联网视角，互联网视角切换到工业信息化视角，不再
本次体会详解
前言：
本次体会的原因，在于处理了一个较大的生产线进度管控系统。在投入开发初期，被告知可能有高达200组参数需要处理，这200组参与，由于可能来自于同一个plc，所以这就意味着需要启动200个线程。项目风险瞬间出现一条：开发的软件能否满足并行200线程？
前期结论：
针对这个特点，技术试验显然是必不可少的，所以我在初期就写了一段测试代码，当时的结论很笼统：200线程执行没问题，但是启动很慢。
本次结论：
1，32位与64位的问题。随着cpu多核的增加，传统32位系统应用显然不在能发挥更多内核优势，实测边界刚好为32核，在控制内核启用的相关逻辑上，最大使用的位掩码局限于31位，也就是说32位应用，不控制数量反而有可能发挥32个核心性能，控制数量则最大成了31个内核。这里引发了一个小细节，编译时候为了发挥多核优势，一定要选x64架构。
2，多线程的启动特点。如果不是我这次要开发一个高达200线程的测试，可能我都注意不到这个细节。多线程的启动，无论是Task，还是Parallel。都表现出同一个特点：等于内核数量的线程瞬间启动，然后大约每秒启动一个新线程。观察到这里，终于知道了之前测试结论中的启动慢原因，而且还进一步知道了多少个线程在多少内核环境下的启动耗时估算公式。
3，补充：就在我认为刚刚找到结论的时候，写下本文第二天就找到了另外的参数，可以直接设置线程池最小值，直接解决了前面的所有问题，宣告之前那段工作过程失败的同时，也直线上升了一下解题问题的思路。
原文地址：
https://www.opengps.cn/Blog/View.aspx?id=3048
文章的更新编辑依此链接为准。欢迎关注源站原创文章！