本文主要是介绍那些共性的技术思想，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
从嵌入式，ｌｉｎｕｘ内核－＞机器学习（１个多月）－＞ｇｌｕｓｔｅｒｆｓ－＞ｋｖｍ ，ｏｐｅｎｓｔａｃｋ，网络－＞ｄｏｃｋｅｒ生态，到现在决定以后方向为ｇｏｌａｎｇ后端开发＋机器学习，数据挖掘， 出于各种原因，各种考量，大体方向总是变来变去，真心感叹伤不起，也侧面反映我先前还是属于半迷茫阶段，毕竟选择方向也可以理解为投资未来。
反省下，方向的频繁转变，那之前学的是否是白学了呢? 去掉那些各个领域的逻辑，到底学了什么了。终结下来，其实还是有很多共性，很多东西底层思想都一样，不管何领域都会使用到。个人觉得，根本原因是 在基础架构没变，都是跑在图灵机机情况下，遇到的问题很多都是共性的，解决的方法思路当然也就相似，这个不会随着开发语言，平台而改变，只不过实现的差异罢了。
当然，无论如何，不是往一个领域方向专一研究，总是伤不起的，没有真正的核心竞争力。
高并发： 协程 epoll
epoll ：无论golang的sysmon线程监控网络，nodejs的非阻塞式回调机制（观察者模式），还是python的evnetlet ，glusterfs分布式文件系统进程之间的通信，看它们的原理，都会看到epoll的影子，毕竟一切都依赖系统嘛。
协程：线程切换，是系统的工作，开销比较大， 而协程是用户态，通过栈来实现，不用切换到内核态，按需动态创建资源，可见更加的灵活高效， 如何利用好多核，进一步提高并发，这就看实现了。
相关链接: goroutine背后的系统知识| sizeof(void)
锁问题
需要锁的最根本必要条件：（1）资源共享，(2)并发：
而频繁用锁，锁的范围越大，性能就越影响，不用锁也就需要打破这两条中的一条即可：
并发条件失效：为啥nodejs没有锁的库，通过非阻塞，单线程方式， 但是缺点 就是不能利用好多核的优点了。
资源共享条件失效：如果不用锁机制的话，全局表下常见方式就是通过一个线程分配独立的空间。像内核的CPU变量，软中断的tasklet都是通过绑定到独立的cpu上，也算解除了并发的条件。
缓存， 性能 ，一致性 ，CAP理论
从应用层到, 基本就是哪有IO，哪有就有缓存。缓存好处不用多说，主要就是提高性能嘛。凡是都有两面，提高性能的对面那就是一致性的问题 ，因此，再加一句，哪有cache，哪就有一致性问题，尤其对于分布式系统来说。对于搞存储的，我想CAP理论就并陌生了，多副本情况下，在性能，可用性面前，也就有强一致性和最终一致性的抉择。
so 。凡事都是相对的，，当你获得了什么，批判性想想有没牺牲掉什么，最后来个折中。
相关链接：
CAP理论1 Introduction to Distributed System Design CAP理论2 酷壳 – CoolShell.cn 相关blog
空间换时间思想
我想这是最常见最常用的重要思想，无论以上的说的缓存，还是以下说的内存管理，hash思想 ，算法中的动态规划 ，都属于这是范围。
哪有性能要求几乎也都能看到这身影。
内存管理 ：减少系统调用
那些注重性能的，基本都自己的内存管理机制，多数采用技术也是malloc/map+ hash 。毕竟频繁调用系统接口伤不起，而基础软件很多要求高性能，看golang，redis 都基于tcmalloc，先map大块内存，再自己管理；glusterfs自己的mem_pool；内核的slab机制。。。。
可以看高性能的基础软件通常通过自己管理内存，最根本原因就是尽量减少系统调用， 这也就很好解释为什么一些软件会消耗那么大内存了，（eg:golang ，redis, mongdb ）
分而治之思想
化整为零，拷贝网络一段解释：任何一个可以用计算机求解的问题所需的计算时间都与其规模有关。问题规模越小，解题所需的计算时间往往也越少，从而也越容易计算。想解决一个较大的问题， 有时是相当困难的。分治法的思想就是，将一个难以直接解决的大问题，分割成一些规模较小的相同问题，以便各个击破，分而治之。分治的基本思想是将一个规模为n的问题分解为k个规模较小的子问题，这些子问题互相独立且与原问题相同。找出各部分的解，然后把各部分的解组合成整个问题的解。
例子：1.对于那些不能一次性载入内存的大文件进行排序，基本思路拆分成小文件快速排序，然后再归并排序了；像现在大数据处理MapReduce ;更广义，数据分片传输，再合并；大文件分片存储在不同节点上，访问时候再从各个节点上获取， 我想在大数据时代下，，分而治之思想也很常见的。
相关链接：海量数据处理：十道面试题与十个海量数据处理方法总结
简单唯美
大道至简，无论解决问题，还是理论。感觉有些只可意会不可言传。
二八定律
编程思想
《深入浅出设计模式》就总结的很好了：
封装变化（抽象！！）
多用组合，少用继承。
针对接口编程，而不针对实现编程。
我觉得这本书所说的基本原则中，最基本的就是这3条了，其他原则，设计模式都能看到影子，扩展出来的。 我想只要很好理解，实践这3条，就比较容易写出灵活，扩展性好，维护性好的代码框架来吧。
并且，就算没见过这本书，也能自然而然的写出能找到对应设计模式名的代码，毕竟设计模式更确切的称呼是常见的“编程经验”。
就好比下象棋久了，然后再给你看给新手的棋谱，估计都有这样的想法：原理我这样的下法还有这么高大上的名字啊。
现在想想，相对于其他传统的面向对象语言（c++，python等等），golang不就很好的精简的体现了3条，这才是面向对象的最简公式，简单唯美！
ps: 还是强烈推荐 酷壳 – CoolShell.cn ，每次看，都有不同的感悟，感慨。毕竟是牛人的多年经验，总结。
ps ：哪有理解错误，望指出，谢谢！
这篇关于那些共性的技术思想的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
