临时备忘录

StackOverflowError

http://www.cnblogs.com/stefanking/articles/5434043.html

where和having：

Where 子句是用来指定 "行" 的条件的，而Having 子句是指定 “组” 的条件的，即
Where 子句 = 指定行所对应的条件
Having 子句 = 指定组所对应的条件
其次，当在Where子句和Having子句中都可以使用的条件，从语句的执行效率来看，最好写在Where子句中。
在使用Count函数等对表中的数据进行聚合操作时，DBMS内部会进行排序处理，而排序操作会增加机器的负担，减少排序的行数，可以增加处理速度。
使用Where子句指定条件时，由于排序之前就对数据进行了过滤，所以能够减少排序的数据量。但是Having子句是在排序之后才对数据进行分组的，因此与前者相比，需要排序的数据量就要多得多。
第三，使用Where子句更具速度优势的另一个理由是，可以对Where子句指定条件所对应的列创建索引，这样可以大幅提高处理速度。
第四，Where子句中不能使用聚合函数，而Having子句中可以。

http://www.cnblogs.com/bluecountry/p/5571244.html

in和exist

IN : 确定给定的值是否与子查询或列表中的值相匹配。in在查询的时候，首先查询子查询的表，然后将内表和外表做一个笛卡尔积，然后按照条件进行筛选。所以相对内表比较小的时候，in的速度较快。

EXIST : 指定一个子查询，检测行的存在。遍历循环外表，然后看外表中的记录有没有和内表的数据一样的。匹配上就将结果放入结果集中。

使用exists关键字进行查询的时候，首先，我们先查询的不是子查询的内容，而是查我们的主查询的表

in 和 exists的区别: 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。其实我们区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键)，如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询，所以我们会以驱动表的快速返回为目标，那么就会考虑到索引及结果集的关系了 ，另外IN时不对NULL进行处理。

in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询。一直以来认为exists比in效率高的说法是不准确的。

参考 ：http://www.cnblogs.com/liyasong/p/sql_in_exists.html

多态：

同一操作作用于不同对象，可以有不同的解释，有不同的执行结果，这就是多态，简单来说就是：父类的引用指向子类对象

 所谓多态就是指程序中定义的引用变量所指向的具体类型和通过该引用变量发出的方法调用在编程时并不确定，而是在程序运行期间才确定，即一个引用变量倒底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法，必须在由程序运行期间才能决定。因为在程序运行时才确定具体的类，这样，不用修改源程序代码，就可以让引用变量绑定到各种不同的类实现上，从而导致该引用调用的具体方法随之改变，即不修改程序代码就可以改变程序运行时所绑定的具体代码，让程序可以选择多个运行状态，这就是多态性。

前期和后期绑定变量说明：http://www.cnblogs.com/startRuning/p/5673485.html

数组和链表

数组是将元素在内存中连续存放，由于每个元素占用内存相同，可以通过下标迅速访问数组中任何元素。但是如果要在数组中增加一个元素，需要移动大量元素，在内存中空出一个元素的空间，然后将要增加的元素放在其中。同样的道理，如果想删除一个元素，同样需要移动大量元素去填掉被移动的元素。如果应用需要快速访问数据，很少或不插入和删除元素，就应该用数组。

链表恰好相反，链表中的元素在内存中不是顺序存储的，而是通过存在元素中的指针联系到一起。比如：上一个元素有个指针指到下一个元素，以此类推，直到最后一个元素。如果要访问链表中一个元素，需要从第一个元素开始，一直找到需要的元素位置。但是增加和删除一个元素对于链表数据结构就非常简单了，只要修改元素中的指针就可以了。如果应用需要经常插入和删除元素你就需要用链表数据结构了。

   *C++语言中可以用数组处理一组数据类型相同的数据，但不允许动态定义数组的大小，即在使用数组之前必须确定数组的大小。而在实际应用中，用户使用数组之前有时无法准确确定数组的大小，只能将数组定义成足够大小，这样数组中有些空间可能不被使用，从而造成内存空间的浪费。链表是一种常见的数据组织形式，它采用动态分配内存的形式实现。需要时可以用new分配内存空间，不需要时用delete将已分配的空间释放，不会造成内存空间的浪费。　

(1) 从逻辑结构角度来看
　　   a, 数组必须事先定义固定的长度（元素个数），不能适应数据动态地增减的情况。当数据增加时，可能超出原先定义的元素个数；当数据减少时，造成内存浪费。
　　   b,链表动态地进行存储分配，可以适应数据动态地增减的情况，且可以方便地插入、删除数据项。（数组中插入、删除数据项时，需要移动其它数据项）
　　(2)从内存存储角度来看
　　   a,(静态)数组从栈中分配空间, 对于程序员方便快速,但自由度小。
　　   b, 链表从堆中分配空间, 自由度大但申请管理比较麻烦.

三次握手：

 对于ChannelOption.SO_BACKLOG的解释： 服务器端TCP内核维护有两个队列，我们称之为A、B队列。客户端向服务器端connect时，会发送带有SYN标志的包（第一次握手），服务器端接收到客户端发送的SYN时，向客户端发送SYN ACK确认（第二次握手），此时TCP内核模块把客户端连接加入到A队列中，然后服务器接收到客户端发送的ACK时（第三次握手），TCP内核模块把客户端连接从A队列移动到B队列，连接完成，应用程序的accept会返回。也就是说accept从B队列中取出完成了三次握手的连接。A队列和B队列的长度之和就是backlog。当A、B队列的长度之和大ChannelOption.SO_BACKLOG时，新的连接将会被TCP内核拒绝。 所以，如果backlog过小，可能会出现accept速度跟不上，A、B队列满了，导致新的客户端无法连接。要注意的是，backlog对程序支持的 连接数并无影响，backlog影响的只是还没有被accept取出的连接 。