格局
格局是一个人的上限。就如你人生的容量，如果格局太小，就是在多的财富，在多的福气，你也接受不了的，会很快散尽的。 犹若水桶，你就一个1L的水桶，一下给你10L的水（运来），也只是从你这不断的溢出而已，等注入结束（运去）你最多也就剩下1L而已，而一般这样的大水流（大运）是冲击较大的，等去了，你其实1L也不会满的。 继续阅读“格局，经历与读书”
查找bug原因的一些个人经验
个人经验和操作：
根据实际情况步骤会有跳过和循环。
1. 弄清楚环境
1.1 对于客户端和偏硬件的，环境影响很大的，可能是某地方兼容没做好，或者直接没支持。
1.2 对于 server 端， 依赖的的内核或者某个dll版本不对，功能异常或者直接崩溃都有可能。
1.3 弄清楚环境也是必现必须的，因为可能实际机器没有开发机器配置高也会有莫名的问题，一不小心高估板子的能力，你在模拟环境怎么都不会必现的。
2. 问清楚操作（访问的接口），和 输入输出
2.1 根据操作和访问的接口，才能知道问题大概的位置，和其依赖的模块
2.2 弄清楚数据，才能去做模拟和复现
3. 确认业务逻辑
3.1 对于有些操作，要先确认业务逻辑是否理解的正确，这是解决问题的关键，由于沟通和经验，定位不一样，对同样的东西理解是有偏差的，一点逻辑偏差，不确认的话，一直沉溺在自己的理解，是不可能准确定位到问题的。
3.2 何况有些时候是你接手的代码，本来就一头雾水，如果代码写的乱，不清楚逻辑就没法搞了。
上面 是准备工作，下面就要真正去确定问题的原因了。
如果代码都是自己写的，基于上面准备工作弄清楚了，如果是逻辑问题，那么你心里应该有个数了，就是不确定，也应该大概确定到问题可能出现在那块代码了。
4. 静态分析可能出问题的代码
4.1 如果代码是自己写的，在心中模拟整个代码执行流程。个人经验，很多问题其实就是一个不小心代码写错导致的问题，例如变量名弄错（重用），逻辑太复杂，一个判断条件出问题，使用错误的api，或者少处理了一种情况。静态分析下自己的代码，可能有一半的bug，其实已经解决了。如果解决不了，也应该知道就是接着处理，在哪里断点 和 加日志也都有数了。
4.2 如果代码不是自己写的，核对代码执行逻辑，确认关键点。别人同样会犯自己犯的错误。在静态分析中也顺便梳理下别人的思路，找出关键点。便于下步操作。
4.5 对于段错误我的一般处理
对于段错误，这个太正常，而且不好处理。我的一般处理是，直接debug运行（gdb或者IDE中debug），不加断点。 等其崩溃，然后查看堆栈信息。当然有core文件，就可以直接查看堆栈信息了，然后根据堆栈去静态分析。 如果是必现，每次位置一样，那么静态分析90%都处理了，不用log和断点那么麻烦了。如果每次位置不一样，或者不必现，那么一般都是线程安全搞鬼了，不好查，先梳理下共享的变量吧。
5. log 和 断点
5.1 如果有条件，断点最好，更直观。对于 server 和 偏硬件的，不好直接断点的，就只能日志了。其实都是获取执行过程中的状态。
6. 等等吧 和 甩锅吧
如果上面你还定位不到问题，那么可能是下面情况了：
6.1 思维走入误区了，那就放放吧，转手忙点其他的吧，过会在回来想，可能就豁然开朗，找到问题了。
6.2 不是现在的我能解决的，老实去求助吧。google， 同事， 群里大牛们。如果是请教人，注意先描述清楚直接问题，环境 和 操作。至于你自己的分析和猜想，可说可不说，最好是说下，但是必须在上面的前提下。注意X，Y 问题，不要把你猜想和分析遇到问题当作问题去问！
6.3 可能真不是你的问题，依赖环境问题，这个就要去查资料确认，能找到源头最好。找不到反正你模拟没问题，先拖着呗。
上面罗嗦一大堆，都是查找问题的，至于解决问题，找到原因了，还有解决不了的问题？不能直接解决，绕着走啊。
其实楼上简单的总结很到位的，其实几个字的事： 调查->分析（猜）->验证。
不如D：3)从输出hello说起
此篇开始不如D系列正式开始D语言的一系列教程。本系列非系统性教程，对于一些基本概念和约定很多都不会介绍，而且地方会与其他语言对比。笔者设想的思路是从例子入手，面向有编程基础的人士，一篇处理一个例子，在解释例子的同时，引入D语言的一些特性介绍和使用教程。这就注定不会有完全整体的教程顺序和很详细的基础介绍。如果想完整的学习D语言，可以先把《D语言程序设计》(百度网盘下载) 这本书过一下（注：D语言发展很快，书中有的细节在最新编译器下已经有不适用的地方了。此书也比较基础，D的高级用法很多都未提及）。由于笔者没有经验和角度已经不完全新手新手，可能行文的顺序和侧重点比较乱。有不足之处还请评论指出。
Hello World
说到编程语言，开篇地一个教程例子，非hello world莫属。我们也就先学习和分析D中的hello world。
import std.stdio;
int main()
{
writeln("Hello world!"); // 输出 Hello world 到控制台
return 0;
}
不如D：2)官网主页例子解析
这篇，我们先从进入官网的例子开始见识下D的强大。
此篇不是入门介绍，没有D基础，不要深究里面的实现细节，当开阔眼界即可。
进入D官网，就有一个例子，那个例子加上注释也就17行代码， 真正main函数里就一句代码，但是却完成了：从控制台按行读取，然后正则提取可能是浮点数的数，把其替换为四舍五入后的整数，然后在输出。 继续阅读“不如D：2)官网主页例子解析”
不如D：1)开篇说明
想写个D的系列介绍和用法的想法有很长时间了，但是由于个人比较懒惰，而且写作不及格，一直迟迟没有动手。今天在知乎上又看到rust和kotlin的专栏了，就决定必须动手了。
这两年用D语言，也算入门了，应该不会出现误人子弟的错误，自己写作向来没有条理，也希望能组织出来条理， 继续阅读“不如D：1)开篇说明”
垃圾回收介绍与D语言内存管理
此文是个ppt的分享，主要内容是：
- GC 算法的基本介绍
- D语言的GC的介绍
- D语言内存管理的方法
- 混合管理字节的经验
相信见ppt：
PPT 内容顺序：
一、 GC 相关概念与基本算法
先介绍三种基本GC算法： 继续阅读“垃圾回收介绍与D语言内存管理”
[转]一个专家眼中的Go与Java垃圾回收算法大对比
我最近看过一堆宣传 Go 语言的最新垃圾收集器的文章。 其中一些文章来自 Go 项目本身。 他们声称 GC 技术发生了根本性的突破。
以下是 2015 年 8 月新垃圾收集器的公告：
Go 正在构建一个垃圾收集器（GC），不仅是为了了 2015 年，同时也为 2025 以及更远的未来…… stw 停顿不再是使用 Go 语言的障碍。在将来，应用程序随着硬件轻松地扩展，并且跟随硬件一起变得更加强大，GC 不会成为软件可扩展性的绊脚石。
D语言中的值类型，引用类型和函数传递方式
D语言内存管理杂谈
D是一个系统级语言，但是也是一个GC语言（虽然现在GC在可选化，但是有的语言特性是基于GC的，例如：关联数组，数组连接等等）。D是GC语言，但不是全GC语言，D同时也提供了简单的手动管理内存的方式。所以下面我就分为GC，NoGC的方式来说。
Qt信号槽的一些事
注：此文是站在Qt5的角度说的，对于Qt4部分是不适用的。
1.先说Qt信号槽的几种连接方式和执行方式。
1）Qt信号槽给出了五种连接方式：
| Qt::AutoConnection | 0 | 自动连接：默认的方式。信号发出的线程和糟的对象在一个线程的时候相当于：DirectConnection， 如果是在不同线程，则相当于QueuedConnection |
| Qt::DirectConnection | 1 | 直接连接：相当于直接调用槽函数，但是当信号发出的线程和槽的对象不再一个线程的时候，则槽函数是在发出的信号中执行的。 |
| Qt::QueuedConnection | 2 | 队列连接：内部通过postEvent实现的。不是实时调用的，槽函数永远在槽函数对象所在的线程中执行。如果信号参数是引用类型，则会另外复制一份的。线程安全的。 |
| Qt::BlockingQueuedConnection | 3 | 阻塞连接：此连接方式只能用于信号发出的线程（一般是先好对象的线程） 和 槽函数的对象不再一个线程中才能用。通过信号量+postEvent实现的。不是实时调用的，槽函数永远在槽函数对象所在的线程中执行。但是发出信号后，当前线程会阻塞，等待槽函数执行完毕后才继续执行。 |
| Qt::UniqueConnection | 0x80 | 防止重复连接。如果当前信号和槽已经连接过了，就不再连接了。 |