smart_an的专栏

3位1体学习法（码农最正确的学习姿势）文章目录3位1体学习法（码农最正确的学习姿势）前言讲师介绍何为3位1体打法？1、第1位2、第2位3、第3位结语前言3位1体这个概念来源于刘慈欣的科幻小说《三体》，smart哥本人非常喜欢这部小说，感叹作者作为一个技术狂，他这种技术狂特有的冷酷具有非凡的吸引力，更关键的是他天马行空的想象。基于这个概念smart哥独创了3位1体的码农学习法，该学习法是码农在浩瀚的技术海洋中的指南针，面对浩瀚的技术和自己有限的职业生涯，那么码农如何自处？35岁后被淘汰还是继续保持优良

CLion调试redis6源码（全网首发）文章目录CLion调试redis6源码（全网首发）背景一、安装配置cygwin二、安装clion三、clion中导入redis源码四、修改CMakeLists.txt文件五、编译&调试redis6源码六、注意点背景clion使用cmake来管理编译redis源码，而redis源码本身使用原生的make，因此直接将redis源码导入clion无法直接运行，需要配置cmake。写c程序大体步骤为：1).用编辑器编写源代码，如.c文件。2).用编译器编

tomcat的底层网络NIO通信基于主从Reactor多线程模型。它有三大线程组分别用于处理不同的逻辑：Acceptor线程：等待和接收客户端连接。在接收到连接后，创建SocketChannel并将其注册到poller线程。poller线程：将SocketChannel放到selector上注册读事件，轮询selector，获取就绪的SelectionKey，并将就绪的SelectionKey（或SocketChannel）委托给工作线程。工作线程：执行真正的业务逻辑。备注：Accep...

Tomcat作为一个服务器来讲，必然运行着很多的线程，而每一个线程究竟是干什么的，这个需要非常的清楚，无论是打印断点，还是通过jstack进行线程栈分析，这都是必须要掌握的技能。 本文带你基于Tomcat7，8，9的版本，识别Tomcat堆栈中的线程。1、main线程main线程是tomcat的主要线程，其主要作用是通过启动包来对容器进行点火：main线程一路启动了Catalina，StandardServer[8005]，StandardService[Catalina]，Standar.

我承认，Lombok是一个很不错的Java库，它可以让你在少写代码的同时耍耍酷，简单的几个注解，就可以干掉一大片模板代码。但是，所有的源代码很多时候是用来阅读的，只有很少的时间是用来执行的(你可以细品这句话)。一年以前，我和大多数人都认为Lombok的出现会让Java的编码体验会更好，并极力的在我的团队中推荐使用Lombok。一年以后，我开始对此产生顾虑，尤其是在我准备为开源的博客系统Una-Boot升级Java版本时，我才意识到Lombok自己掉入了一个戏法陷阱。在我进一步分析其源代码并理解相关注解的

本来打算写一篇《阿里巴巴为什么不允许日志输出时，使用字符串拼接？》的文章，主要是想从性能方面来说此问题，可在文章写到一半进行性能测试时，却发现了一个异常问题，实际测试的结果和手册上描述的结果是截然相反的！天撸了，怎么会发生这种事情？此时我的内心是拒绝的，因为文章已经写了一半了啊，这让我瞬间陷入了尴尬的境地。阿里巴巴的《Java开发手册》泰山版（最新版）是这样描述的，它在第二章第三小节的第 4 条规范中指出：【强制】在日志输出时，字符串变量之间的拼接使用占位符的方式。说明：因为 String

这个问题很容易理解，一个单节点（一台应用服务器+一台数据库服务器）的系统架构，任凭你使出浑身解数来调优也不可能让系统达到百万级并发，别说百万级了，上万并发都不可能。不说其他的，在一个性能相对不错的物理机上，mysql最多也就能承载3500-4500的QPS，你说你能调优调到上万并发？？在目前来看如果不借助于其他组件或者其他技术手段是不太可能的。首先大家要明白一个最底层的逻辑，所有的性能问题归根结底绝大多数都是要解决IO的读写性能问题。我们在线程模型上面孜孜不倦的追求，从BIO到NIO，再到react

我们在做项目时候一般会遇到下面的问题：问题一是不知道如何去设计，比如刚入职场时，来一个需求需做概要设计，不知如何下手，不得不去看当前系统类似需求是如何设计的，然后仿照去设计。 问题二是设计的时候，考虑问题不周全，相比职场新手，这类人对一个需求依靠自己的经验已经能够拿出一个概要设计，但是设计中经常会遗漏一些异常细节，比如使用多线程有界队列执行任务，遇到机器宕机了，如果队列里面的任务不存盘的话，那么机器下次启动时候这些任务就丢失了。对于这些问题，说到底主要是因为经验不够，而经验主要从项目实践中积累，所以

【悟思维】项目架构决定性能？优秀的架构胜过一万次的调优这个问题很容易理解，一个单节点（一台应用服务器+一台数据库服务器）的系统架构，任凭你使出浑身解数来调优也不可能让系统达到百万级并发，别说百万级了，上万并发都不可能。不说其他的，在一个性能相对不错的物理机上，mysql最多也就能承载3500-4500的QPS，你说你能调优调到上万并发？？在目前来看如果不借助于其他组件或者其他技术手段是不太可能的。首先大家要明白一个最底层的逻辑，所有的性能问题归根结底绝大多数都是要解决IO的读写性能问题。我们在线

性能优化无非就是线程，cpu调度，以及内存之间的配合，这三者中任何一个达到极限，都会造成系统整体性能下降，甚至瘫痪。线程必然要由cpu调度才能活动起来，那么线程的活动也必须有自己的地盘，那么这个地盘就是内存区域。线程数越多，需要cpu的调度能力越强，需要的内存也就越大，那么线程不可能无限增大，总有个极限，当到达极限之后，系统性能将呈现抛物线形的状态急转往下。所以我们必须不能让cpu等资源达到这个极限值，一般在85%左右就可以了。intel的工程师曾今说过，我们为什么要让cpu达到100%的性能呢，能

因为职业的特殊性，程序员身边的女生较少，又经常加班，外出社交较少，所以导致身边很多程序员朋友，工作了好几年还是单身。虽然我自身找了好久才交往到如今的女票，但我觉得找女朋友这件事不是纯靠运气和缘分，它也有方法论可言的。那就是以实验为基础，不停迭代的增长黑客思维模型。增长模式几年前就从硅谷诞生了，最近一两年才在国内流行起来。它不仅能用在公司的增长上，也可以运用到人生的各个方面上。它不止是一个概...