1. 字节对齐
现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐。
对齐的作用和原因：各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问 一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况，但是最常见的是如果不按照适合其平台要求对 数据存放进行对齐，会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始，如果一个int型（假设为32位系统）如果存放在偶地址开始的地方，那 么一个读周期就可以读出这32bit，而如果存放在奇地址开始的地方，就需要2个读周期，并对两次读出的结果的高低字节进行拼凑才能得到该32bit数 据。显然在读取效率上下降很多。
2.虚函数原理
虚函数是为了实现多态。多态的实现需要虚函数和动态绑定技术。实现方式：基类使用虚函数；
子类覆盖该函数；用一个基类的指针或引用只想子类对象，在运行的过程中，通过查找该对象的虚函数表实现多态。虚函数表在每个对象最开始的地方。
3.函数指针
int(f)(int) 函数指针
int(f[10])(int) 函数指针数组
4.编译器和连接器和加载器的问题
编译器和汇编器创建了目标文件（包含由源程序生成的二进制代码和数据）。链接器
将多个目标文件合并成一个，加载器读取这些目标文件并将它们加载到内存中（在一个集成
编程环境中
一个目标文件包含五类信息。
● 头信息：关于文件的整体信息，诸如代码大小，翻译成该目标文件的源文件名称，
和创建日期等。
● 目标代码：由编译器或汇编器产生的二进制指令和数据。
● 重定位信息：目标代码中的一个位置列表，链接器在修改目标代码的地址时会对它
进行调整。
● 符号：该模块中定义的全局符号，以及从其它模块导入的或者由链接器定义的符号。
● 调试信息：目标代码中与链接无关但会被调试器使用到的其它信息
5. select, poll 和epoll的原理和区别
在Linux Socket服务器短编程时，为了处理大量客户的连接请求，需要使用非阻塞I/O和复用，select、poll和epoll是Linux API提供的I/O复用方式
（1）select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述副就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但 是这样也会造成效率的降低。
（3）不同与select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。
pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。 和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。
从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。
（3）主要是epoll_create,epoll_ctl和epoll_wait三个函数。epoll_create函数创建epoll文件描述符，参数size并不是限制了epoll所能监听的描述符最大个数，只是对内核初始分配内部数据结构的一个建议。返回是epoll描述符。-1表示创建失败。epoll_ctl 控制对指定描述符fd执行op操作，event是与fd关联的监听事件。op操作有三种：添加EPOLL_CTL_ADD，删除EPOLL_CTL_DEL，修改EPOLL_CTL_MOD。分别添加、删除和修改对fd的监听事件。epoll_wait 等待epfd上的io事件，最多返回maxevents个事件。
在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一 个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知。
epoll的优点主要是一下几个方面：
a. 监视的描述符数量不受限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。select的最大缺点就是进程打开的fd是有数量限制的。这对 于连接数量比较大的服务器来说根本不能满足。虽然也可以选择多进程的解决方案( Apache就是这样实现的)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也 不是一种完美的方案。
b. IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。
c. 支持电平触发和边沿触发（只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发）两种方式，理论上边缘触发的性能要更高一些，但是代码实现相当复杂。
d. mmap加速内核与用户空间的信息传递。epoll是通过内核于用户空间mmap同一块内存，避免了无畏的内存拷贝。
6.stl的sort是如何实现的
STL的sort()算法，数据量大时采用Quick Sort，分段递归排序，一旦分段后的数据量小于某个门槛，为避免Quick Sort的递归调用带来过大的额外负荷，就改用Insertion Sort。如果递归层次过深，还会改用Heap Sort。
为什么是Insertion Sort，而不是Bubble Sort。
选择排序(Selection sort)，插入排序(Insertion Sort)，冒泡排序(Bubble Sort)。这三个排序是初学者必须知道的三个基本排序方式，且他们速度都不快 – O(N^2)。选择排序就不说了，最好情况复杂度也得O(N^2)，且还是个不稳定的排序算法，直接淘汰。
可冒泡排序和插入排序相比较呢？
首先，他们都是稳定的排序算法，且最好情况下都是O(N^2)。那么我就来对他们的比较次数和移动元素次数做一次对比（最好情况下），如下：
插入排序：比较次数N-1，移动元素次数2N-1。
冒泡排序：比较次数N-1，无需移动元素。(注：我所说的冒泡排序在最基本的冒泡排序基础上还利用了一下旗帜的方式，即寻访完序列未发生数据交换时则表示排序已完成，无需再进行之后的比较与交换动作）
那么，这样看来冒泡岂不是是更快，我可以把上述的final_insertion_sort()函数改成一个final_bubble_sort()，把每个子序列分别进行冒泡排序，岂不是更好？
事实上，具体实现时，我才发现这个想法错了，因为写这么一个final_bubble_sort()，我没有办法确定每个子序列的大小，可我还是不甘心呐，就把bubble_sort()插在introsort_loop()最后，这样确实是每个子序列都用bubble_sort()又排序了一次，可是测试结果太惨了，由此可以看书Bubble Sort在“几近排序但尚未完成”的情况下是没多少改进作用的。
为什么不直接用Heap Sort
堆排序将所有的数据建成一个堆，最大的数据在堆顶，它不需要递归或者多维的暂存数组。算法最优最差都是O(NlogN)，不像快排，如果你人品够差还能恶化到O(N^2)。当数据量非常大时（百万数据），因为快排是使用递归设计算法的，还可能发出堆栈溢出错误呢。
那么为什么不直接用Heap Sort？或者说给一个最低元素阈值（__stl_threshold)时也给一个最大元素阈值（100W），即当元素数目超过这个值时，直接用Heap Sort，避免堆栈溢出呢？
对于第一个问题，我测试了一下，发现直接用Heap Sort，有时还没有Quick Sort快呢，查阅《算法导论》发现，原来虽然Quick和Heap的时间复杂性是一样的，但堆排序的常熟因子还是大些的，并且堆排序过程中重组堆其实也不是个省时的事。
7.c++11中引入的各种新特性
8. linux的线程同步原语
9.linux查看一个进程打开了哪些句柄
lsof
10. linux下得内存泄露
vargrind检查内存泄露

这是Java与C++区别的一个比较完整的答案，大家可以学习一下。

JAVA和C++都是面向对象语言。也就是说，它们都能够实现面向对象思想（封装，继乘，多态）。而由于c++为了照顾大量的C语言使用者，
而兼容了C，使得自身仅仅成为了带类的C语言，多多少少影响了其面向对象的彻底性！JAVA则是完全的面向对象语言，它句法更清晰，规模更小，更易学。它是在对多种程序设计语言进行了深入细致研究的基础上，据弃了其他语言的不足之处，从根本上解决了c++的固有缺陷。
Java和c++的相似之处多于不同之处，但两种语言问几处主要的不同使得Java更容易学习，并且编程环境更为简单。
我在这里不能完全列出不同之处，仅列出比较显著的区别：
1．指针
JAVA语言让编程者无法找到指针来直接访问内存无指针，并且增添了自动的内存管理功能，从而有效地防止了c／c++语言中指针操作失误，如野指针所造成的系统崩溃。但也不是说JAVA没有指针，虚拟机内部还是使用了指针，只是外人不得使用而已。这有利于Java程序的安全。
2．多重继承
c++支持多重继承，这是c++的一个特征，它允许多父类派生一个类。尽管多重继承功能很强，但使用复杂，而且会引起许多麻烦，编译程序实现它也很不容易。Java不支持多重继承，但允许一个类继承多个接口(extends+implement)，实现了c++多重继承的功能，又避免了c++中的多重继承实现方式带来的诸多不便。
3．数据类型及类
Java是完全面向对象的语言，所有函数和变量部必须是类的一部分。除了基本数据类型之外，其余的都作为类对象，包括数组。对象将数据和方法结合起来，把它们封装在类中，这样每个对象都可实现自己的特点和行为。而c++允许将函数和变量定义为全局的。此外，Java中取消了c／c++中的结构和联合，消除了不必要的麻烦。
4．自动内存管理
Java程序中所有的对象都是用new操作符建立在内存堆栈上，这个操作符类似于c++的new操作符。下面的语句由一个建立了一个类Read的对象，然后调用该对象的work方法：
Read r＝new Read()；
r.work()；
语句Read r＝new Read()；在堆栈结构上建立了一个Read的实例。Java自动进行无用内存回收操作，不需要程序员进行删除。而c十十中必须由程序贝释放内存资源，增加了程序设计者的负扔。Java中当一个对象不被再用到时，无用内存回收器将给它加上标签以示删除。JAVA里无用内存回收程序是以线程方式在后台运行的，利用空闲时间工作。
5．操作符重载
Java不支持操作符重载。操作符重载被认为是c十十的突出特征，在Java中虽然类大体上可以实现这样的功能，但操作符重载的方便性仍然丢失了不少。Java语言不支持操作符重载是为了保持Java语言尽可能简单。
6．预处理功能
Java不支持预处理功能。c／c十十在编译过程中都有一个预编泽阶段，即众所周知的预处理器。预处理器为开发人员提供了方便，但增加丁编译的复杂性。JAVA虚拟机没有预处理器，但它提供的引入语句(import)与c十十预处理器的功能类似。
7. Java不支持缺省函数参数，而c十十支持
在c中，代码组织在函数中，函数可以访问程序的全局变量。c十十增加了类，提供了类算法，该算法是与类相连的函数，c十十类方法与Java类方法十分相似，然而，由于c十十仍然支持c，所以不能阻止c十十开发人员使用函数，结果函数和方法混合使用使得程序比较混乱。
Java没有函数，作为一个比c十十更纯的面向对象的语言，Java强迫开发人员把所有例行程序包括在类中，事实上，用方法实现例行程序可激励开发人员更好地组织编码。
8 字符串
c和c十十不支持字符串变量，在c和c十十程序中使用Null终止符代表字符串的结束，在Java中字符串是用类对象(strinR和stringBuffer)来实现的，这些类对象是Java语言的核心，用类对象实现字符串有以下几个优点：
(1)在整个系统中建立字符串和访问字符串元素的方法是一致的；
(2)J3阳字符串类是作为Java语言的一部分定义的，而不是作为外加的延伸部分；
(3)Java字符串执行运行时检空，可帮助排除一些运行时发生的错误；
(4)可对字符串用“十”进行连接操作。
9“goto语句
“可怕”的goto语句是c和c++的“遗物”，它是该语言技术上的合法部分，引用goto语句引起了程序结构的混乱，不易理解，goto语句子要用于无条件转移子程序和多结构分支技术。鉴于以广理由，Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使用，使程序简洁易读。
l0．类型转换
在c和c十十中有时出现数据类型的隐含转换，这就涉及了自动强制类型转换问题。例如，在c十十中可将一浮点值赋予整型变量，并去掉其尾数。Java不支持c十十中的自动强制类型转换，如果需要，必须由程序显式进行强制类型转换。
11.异常
JAVA中的异常机制用于捕获例外事件，增强系统容错能力
try{／／可能产生例外的代码
}catch(exceptionType name){
//处理
}
其中exceptionType表示异常类型。而C++则没有如此方便的机制。

1、Python是如何进行内存管理的？

Python引用了一个内存池(memory pool)机制，即Pymalloc机制(malloc:n.分配内存)，用于管理对小块内存的申请和释放。

内存池（memory pool）的概念：

当 创建大量消耗小内存的对象时，频繁调用new/malloc会导致大量的内存碎片，致使效率降低。内存池的概念就是预先在内存中申请一定数量的，大小相等 的内存块留作备用，当有新的内存需求时，就先从内存池中分配内存给这个需求，不够了之后再申请新的内存。这样做最显著的优势就是能够减少内存碎片，提升效率。
内存池的实现方式有很多，性能和适用范围也不一样。

python中的内存管理机制——Pymalloc：
python中的内存管理机制都有两套实现，一套是针对小对象，就是大小小于256bits时,pymalloc会在内存池中申请内存空间；当大于256bits，则会直接执行new/malloc的行为来申请内存空间。
关于释放内存方面，当一个对象的 引用计数变为0时，python就会调用它的析构函数。在析构时，也采用了内存池机制，从内存池来的内存会被归还到内存池中，以避免频繁地释放动作。
参考：http://www.360doc.com/content/13/0121/18/9934052_261604074.shtml

http://developer.51cto.com/art/201007/213585.htm

2、什么是lambda函数？它有什么好处?

这涉及到函数式编程，关于lambda。lambda函数也叫匿名函数，返回可调用的函数对象。

复制代码
“””lambda表达式的定义体必须和声明放在同一行”””
print lambda x:True #<function <lambda> at 0x012E10B0>
print lambda y:y2 #<function <lambda> at 0x012B10B0>
“””该对象的引用计数在函数创建时被设置为True，但是因为没有引用保存下来，计数又回到了零，然后被垃圾回收掉
为了保存该对象，需要放在一个变量里，随时调用
这也是为啥叫做匿名
“””
test = lambda y:y2
print test(10) #20
复制代码
好处：

个人认为有以下：

1、对于单行函数，使用lambda可以省去定义函数的过程，让代码更加精简。

2、在非多次调用的函数的情况下，lambda表达式即用既得，提高性能

3、解释一下python的 and-or 语法？

关于and-or语法在《Dive Into Python》一书中有讲解，在《Python核心编程2》并没有提及，只是提到and、or语法，我想关于and-or，或许并没有约定俗成的，而是一种衍生或扩展吧。

and-or主要是用来模仿 三目运算符 bool?a:b的，即当表达式bool为真，则取a否则取b。如下面用js实现：

var s1=2;
var s2=3;
max = s1 > s2 ? s1:s2;//max = 3
但是Python并不支持这个语法，所以就衍生出了and-or

见：www.cnblogs.com/BeginMan/p/3197123.html

4、Python是如何进行类型转换的？

第一点要知道：Python是动态类型，而且是强类型的编程语言。

第二点要知道：Python内建函数的实现类型转换

复制代码
函数 描述
int(x [,base ]) 将x转换为一个整数
long(x [,base ]) 将x转换为一个长整数
float(x ) 将x转换到一个浮点数
complex(real [,imag ]) 创建一个复数
str(x ) 将对象 x 转换为字符串
repr(x ) 将对象 x 转换为表达式字符串
eval(str ) 用来计算在字符串中的有效Python表达式,并返回一个对象
tuple(s ) 将序列 s 转换为一个元组
list(s ) 将序列 s 转换为一个列表
chr(x ) 将一个整数转换为一个字符
unichr(x ) 将一个整数转换为Unicode字符
ord(x ) 将一个字符转换为它的整数值
hex(x ) 将一个整数转换为一个十六进制字符串
oct(x ) 将一个整数转换为一个八进制字符串
复制代码
5、Python里面如何拷贝一个对象？

这个详见我这篇博客【点击阅读】

6、Python中pass语句的作用是什么？

pass语句什么也不做，一般作为占位符或者创建占位程序，pass语句不会执行任何操作。

7、如何知道一个python对象的类型？

复制代码
>>> lis = [1,2,3]
>>> lis.class #获得已知对象的类 ： 对象.class
<type ‘list’>
>>> type(lis)
<type ‘list’>
复制代码
8、介绍一下Python下range()函数的用法？

range(start, stop[, step])
返回列表
复制代码
>>> range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> range(1, 11)
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
>>> range(0, 30, 5)
[0, 5, 10, 15, 20, 25]
>>> range(0, 10, 3)
[0, 3, 6, 9]
>>> range(0, -10, -1)
[0, -1, -2, -3, -4, -5, -6, -7, -8, -9]
>>> range(0)
[]
>>> range(1, 0)
[]
复制代码
http://docs.python.org/2/library/functions.html#range

9、其他

如何用Python来进行查询和替换一个文本字符串？

Python里面search()和match()的区别？

用Python匹配HTML tag的时候，<.>和<.?>有什么区别？

Python里面如何生成随机数？

如何用Python来发送邮件？

有两个序列a,b，大小都为n,序列元素的值任意整形数，无序；
要求：通过交换a,b中的元素，使[序列a元素的和]与[序列b元素的和]之间的差最小。
1. 将两序列合并为一个序列，并排序，为序列Source
2. 拿出最大元素Big，次大的元素Small
3. 在余下的序列S[:-2]进行平分，得到序列max，min
4. 将Small加到max序列，将Big加大min序列，重新计算新序列和，和大的为max，小的为min。

Python如何定义一个函数?

有没有一个工具可以帮助查找python的bug和进行静态的代码分析？

如何在一个function里面设置一个全局的变量？

盘space 都被占满，但是自己实际使用的空间只占1/3，这时候就要考虑是否是缓存文件过大的问题了。
手动编辑如下文件，文件名保存为”清除系统.bat”,单击即可运行。
@echo off
echo 正在清除系统垃圾文件，请稍等……
del /f /s /q “%USERPROFILE%\AppData\Local\Temp”
del /f /s /q %systemdrive%*.tmp
del /f /s /q %systemdrive%*._mp
del /f /s /q %systemdrive%*.log
del /f /s /q %systemdrive%*.gid
del /f /s /q %systemdrive%*.chk
del /f /s /q %systemdrive%*.old
del /f /s /q %systemdrive%\recycled*.
del /f /s /q %windir%\.bak
del /f /s /q %windir%\prefetch*.
rd /s /q %windir%\temp & md %windir%\temp
del /f /q %userprofile%\COOKIES s\.
del /f /q %userprofile%\recent\.
del /f /s /q “%userprofile%\Local Settings\Temporary Internet Files\.“
del /f /s /q “%userprofile%\Local Settings\Temp\.“
del /f /s /q “%userprofile%\recent\.*”
del /f /s /q “%USERPROFILE%\AppData\Local\Temp”
sfc /purgecache ‘清理系统盘无用文件
defrag %systemdrive% -b ‘优化预读信息
echo 清除系统LJ完成！
echo. & pause

如果删除结果还不满意，可参考一下方法：
http://www.to8to.com/yezhu/v2737.html

首先要确定的是Android中不能在子线程中来刷新UI线程。所以必须使用android的handler机制。即：
在主activity中定一个Handler的成员，然后实现handlemassage函数，创建线程后在runable的run函数里new一个message，然后指定message对象的what成员，这个是指定message的一个id，然后在run中调用Handler的成员，使用其成员方法中的sendmessage(好像是叫这个)，handlemassage函数中参数有个massage，根据该message参数中的what来对你发送message时指定的what来处理UI的功能。Handler的实现实例如下：

1
2
3
4
5
6
7
8
9
10
11

private Handler handler = new Handler(){              
            public void handleMessage(Message msg) {  
                switch (msg.what) {  
                    case CASE1:  
                         //获取传递的数据
                         //Bundle data = msg.getData();
                         <strong>//处理UI更新等操作
                         //......</strong>
                }  
            };  
        };

然后可以在任何地方调用这个handler，如下：

1
2
3
4
5
6
7

Message msg = new Message();     
msg.what = CASE1;
//这三句可以传递数据
//Bundle data = new Bundle();
//data.putInt("COUNT", 100);//COUNT是标签,handleMessage中使用
//msg.setData(data);
handler.sendMessage(msg); // 向Handler发送消息,更新UI

原文地址

据 GigaOM消息，Google 上周宣布，将自己用 C++ 开发的 MapReduce 框架MapReduce for C（MR4C）开源，此举可给 Hadoop 社区带来福音，因为这样用户就可以在自己的 Hadoop 环境中运行原生的 C 及 C++ 代码了。

Hadoop 是许多大数据应用的基础，它是由 Apache 基金会所开发的分布式系统基础架构，主要由分布式文件系统 HDFS 和计算框架 MapReduce 组成。由于原先的 MapReduce 是用 Java 编写的，与 C++ 相比，在性能上要略逊一筹，因此，许多处理大规模数据集的软件公司都开发了自己的专有系统来在 MapReduce 框架之内执行其原生代码。Facebook 的 HipHop（将 PHP 转换为 C++）以及 MemSQL 执行前将 SQL 转为 C++ 代码也都是出于同样的性能考虑。

MR4C 原先由卫星影像公司 Skybox Imaging 开发，目的是为了优化其地理空间数据及计算机视觉代码库。MR4C 围绕着几个简单概念开发而成，其目标是将 MapReduce 的重要细节抽象化，允许用户专注于开发有价值的算法。去年 6 月，Google 收购了 Skybox。半年之后的现在，又将 MR4C 开源出来。这对于没有能力开发专有系统或者对 Java 不感冒的开发者来说无疑是一个福音。

当然，MR4C 的受欢迎程度仍有待观察。因为在数据处理方面，Apache Spark 是一个速度比 Mapreduce 更快的框架，它支持 Scala、Python 和 Java（但不支持 C/C++），已经引起了开发社区极大的兴趣。

[消息来源：gigaom.com, google-opensource.blogspot.com]

原文地址

Top1. 数组转换为数组列表

将数组转换为数组列表，开发者经常会这样做：

1

List<String> list = Arrays.asList(arr);

Arrays.asList()将返回一个数组内部是私有静态类的ArrayList，这不是java.util.ArrayList类，java.util.Arrays.ArrayList类有set()、 get()、 contains()方法，但是没有任何加元素的方法，因此它的大小是固定的。你应该这么做来创建一个真正的数组：

1

ArrayList<String> arrayList = new ArrayList<String>(Arrays.asList(arr));

ArrayList的构造函数能够接受一个集合类型，这也是java.util.Arrays.ArrayList的超级类型。

Top2. 检查一个数组包含一个值

开发者经常这么做：

1
2

Set<String> set = new HashSet<String>(Arrays.asList(arr));  
return set.contains(targetValue);

代码可以工作，但是没有必要首先转换列表到Set，转换一个列表到一个Set需要额外的时间。因此你可以把它简化为：

1

Arrays.asList(arr).contains(targetValue);

或

1
2
3
4
5
6

for(String s: arr){  
    if(s.equals(targetValue))  
        return true;  
}  
return false; 
`

第一个比第二个更具可读性

Top3. 在一个循环中从一个列表里删除一个元素

考虑下面删除元素的代码在迭代中的结果：

1
2
3
4
5

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));  
for (int i = 0; i < list.size(); i++) {  
    list.remove(i);  
}  
System.out.println(list);

输出是：

1

[b, d]

该方法有一个严重的问题，当一个元素被删除时，列表收缩的大小以及指针改变了。所以想要在循环内利用指针删除多个元素是无法正常进行的。

这种情况下使用迭代器才是正确的方法，foreach循环在Java中的工作像是一个迭代器，但实际上并不是，考虑下面的代码：

1
2
3
4
5
6

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));  
for (String s : list) {  
    if (s.equals("a"))  
        list.remove(s);  
}

它会报出ConcurrentModificationException异常。

相反下面这个就可以正常工作。

1
2
3
4
5
6
7
8
9

ArrayList<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c", "d"));  
Iterator<String> iter = list.iterator();  
while (iter.hasNext()) {  
    String s = iter.next();  
    if (s.equals("a")) {  
        iter.remove();  
    }  
}

.next()必须在.remove()之前被调用。在foreach循环中，编译器将在删除元素操作之后调用.next()，这也是导致ConcurrentModificationException异常的原因，你可以点击此处查看ArrayList.iterator()的源代码。

Top4. Hashtable vs HashMap

根据算法的常规，Hashtable是对数据结构的称呼。但是在Java中，数据结构的名称是HashMap。Hashtable和HashMap关键不同之一是Hashtable是同步的。

关于这一点可查看以下两个链接：

HashMap vs. TreeMap vs. Hashtable vs. LinkedHashMap

Map问题Top10

Top5. 使用集合的原始类型

在Java中，原始类型和无限制的通配符类型很容易被混淆。以Set为例，Set是原始类型，而Set(?)则是无限制的通配符类型。

考虑下面的代码，以一个原始类型List作为参数：

1
2
3
4
5
6
7
8
9

public static void add(List list, Object o){  
    list.add(o);  
}  
public static void main(String[] args){  
    List<String> list = new ArrayList<String>();  
    add(list, 10);  
    String s = list.get(0);  
} 
`

该代码会抛出一个异常：

1
2

Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String  
    at ...

使用原始类型集合是危险的，因为原始类型集合跳过了泛型类型检查，也不安全。Set、Set<?>和Set

Raw type vs. Unbounded wildcard和Type Erasure。

Top6. 访问级别

开发者经常对类域使用public，这很容易通过直接引用获得域值，但这是一个非常糟糕的设计。根据经验来说是给予成员的访问级别越低越好。

详细情况可点击查看Java中成员访问级别：public、protected、private

Top7.ArrayList VS LinkedList

如果你不知道ArrayList和LinkedList之间的区别时，你可能会经常的选用ArrayList，因为它看起来看熟悉。然而它们之间有巨大的性能不同。简单的来说，如果有大量的添加/删除操作，并且没有很多的随机存取操作时，LinkedList应该是你的首选。如果您对此不是很了解的话，点此此处查看更多关于它们性能的信息。

Top8. Mutable VS Immutable

Immutable对象有很多优势，比如简单、安全等等。但它要求每一个不同的值都需要有一个不同的对象，而太多的对象可能会导致垃圾收集的高成本。所以对Mutable和Immutable的选择应该有一个平衡点。

一般来说，Mutable对象用于避免产生过多的中间对象，经典的例子是连接大量的字符串数。如果你使用Immutable字符串，那么会产生很多符合垃圾收集条件的对象。这对CPU是浪费时间和精力的，当其可以使用Mutable对象作为正确的解决方案。（如StringBuilder）

1
2
3
4

String result="";  
for(String s: arr){  
    result = result + s;  
}

这里还有一些其他Mutable对象可取的情况。例如mutable对象传递到方法中允许你在不跳过太多语法的情况下收集多个结果。另一个例子是排序和过滤，你可以构建一个带有原有集合的方法，并返回一个已排序的，不过这对大的集合来说会造成更大的浪费。

推荐阅读：为什么字符串是Immutable？

Top9. Super和Sub构造函数

这个编译错误是因为默认的Super构造函数是未定义的。在Java中，如果一个类没有定义一个构造函数，编译器会默认的为类插入一个无参数构造函数。如果一个构造函数是在Super类中定义的，这种情况下Super(String s)，编译器不会插入默认的无参数构造函数。

另一方面，Sub类的构造函数，无论带不带有参数，都会调用无参数的Super构造函数。

编译器在Sub类中试图将Super()插入到两个构造函数中，但是Super默认的构造函数是没有定义的，编译器才会报错。如何解决这一问题？你只需在Super类中添加一个Super()构造函数，如下所示：

1
2
3

public Super(){  
    System.out.println("Super");  
}

或移除自定义的Super构造函数，又或者在Sub函数中添加super(value)。

这方面想了解更多的可以点击此处查看。

Top10. “”或构造函数？

字符串可以通过两种方式创建：

1
2
3
4

//1\. use double quotes  
String x = "abc";  
//2\. use constructor  
String y = new String("abc");

它们之间有何不同？下面的例子可以给出答案：

1
2
3
4
5
6
7
8
9

String a = "abcd";  
String b = "abcd";  
System.out.println(a == b);  // True  
System.out.println(a.equals(b)); // True  
String c = new String("abcd");  
String d = new String("abcd");  
System.out.println(c == d);  // False  
System.out.println(c.equals(d)); // True

关于它们如何在内存中分布的更多细节可以查看《使用””或构造函数创建Java字符串》。

推荐阅读：

Constructors of Sub and Super Classes in Java?

How Developers Sort in Java?

How to Convert Array to ArrayList in Java?

Java Type Erasure Mechanism

原文来自：programcreek

首先要确定mac系统上有没有安装jdk，并查看自己的jdk版本，可以在终端上输入命令 java -version查看。如果没有安装jdk请先安装jdk，安装方法就不多说了，可以去Oracle官网上下载安装。
接下来确定自己的jdk版本，如果jdk的版本不是1.6版本就有可能出现以上问题，无法启动Android Studio。原因在于Android Studio的配置文件中默认要求的是1.6版本的JVM，所以可以简单的修改下Android Studio的配置文件。方法如下：
1.找到你的Android Studio.app文件位置，一般都是在Applications文件夹下面。
2.选择Android Studio.app文件，打开右键菜单，选择Show Package Contents打开Android Studio.app（其实Mac系统下的app文件就是一个特殊的文件夹）。
3.进入Contents文件夹，找到Info.plist配置文件。
4.可以打开Info.plist配置文件，找到其中的JVMVersion标签，可以看到这个标签下面为1.6，默认使用JVM1.6版本，现在最新的JDK已经是1.8了。把1.6改成你所安装的jdk版本号然后保存修改就可以解决这个问题，或者简单的改成1.6+就可以兼容1.6以上的jdk版本。

这是编码问题，需要将相应行改为utf8格式，在mysql的控制台里输入以下命令：

1

ALTER TABLE `TABLENAME` CHANGE `CLOUMNNAME` `COLUMNNAME` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL

需要将相应的TABLENAME和COLUMNNAME替换为相应的表名和列名。

原文地址
1. 背景

1.1. Netty 3.X系列版本现状

根据对Netty社区部分用户的调查，结合Netty在其它开源项目中的使用情况，我们可以看出目前Netty商用的主流版本集中在3.X和4.X上，其中以Netty 3.X系列版本使用最为广泛。

Netty社区非常活跃，3.X系列版本从2011年2月7日发布的netty-3.2.4 Final版本到2014年12月17日发布的netty-3.10.0 Final版本，版本跨度达3年多，期间共推出了61个Final版本。

1.2. 升级还是坚守老版本

相比于其它开源项目，Netty用户的版本升级之路更加艰辛，最根本的原因就是Netty 4对Netty 3没有做到很好的前向兼容。

由于版本不兼容，大多数老版本使用者的想法就是既然升级这么麻烦，我暂时又不需要使用到Netty 4的新特性，当前版本还挺稳定，就暂时先不升级，以后看看再说。

坚守老版本还有很多其它的理由，例如考虑到线上系统的稳定性、对新版本的熟悉程度等。无论如何升级Netty都是一件大事，特别是对Netty有直接强依赖的产品。

从上面的分析可以看出，坚守老版本似乎是个不错的选择；但是，“理想是美好的,现实却是残酷的”，坚守老版本并非总是那么容易，下面我们就看下被迫升级的案例。

1.3. “被迫”升级到Netty 4.X

除了为了使用新特性而主动进行的版本升级，大多数升级都是“被迫的”。下面我们对这些升级原因进行分析。

公司的开源软件管理策略：对于那些大厂，不同部门和产品线依赖的开源软件版本经常不同，为了对开源依赖进行统一管理，降低安全、维护和管理成本，往往会指定优选的软件版本。由于Netty 4.X 系列版本已经非常成熟，因为，很多公司都优选Netty 4.X版本。
维护成本：无论是依赖Netty 3.X，还是Netty4.X，往往需要在原框架之上做定制。例如，客户端的短连重连、心跳检测、流控等。分别对Netty 4.X和3.X版本实现两套定制框架，开发和维护成本都非常高。根据开源软件的使用策略，当存在版本冲突的时候，往往会选择升级到更高的版本。对于Netty，依然遵循这个规则。
新特性：Netty 4.X相比于Netty 3.X,提供了很多新的特性，例如优化的内存管理池、对MQTT协议的支持等。如果用户需要使用这些新特性，最简便的做法就是升级Netty到4.X系列版本。
更优异的性能：Netty 4.X版本相比于3.X老版本，优化了内存池，减少了GC的频率、降低了内存消耗；通过优化Rector线程池模型，用户的开发更加简单，线程调度也更加高效。
1.4. 升级不当付出的代价

表面上看，类库包路径的修改、API的重构等似乎是升级的重头戏，大家往往把注意力放到这些“明枪”上，但真正隐藏和致命的却是“暗箭”。如果对Netty底层的事件调度机制和线程模型不熟悉，往往就会“中枪”。

本文以几个比较典型的真实案例为例，通过问题描述、问题定位和问题总结，让这些隐藏的“暗箭”不再伤人。

由于Netty 4线程模型改变导致的升级事故还有很多，限于篇幅，本文不一一枚举，这些问题万变不离其宗，只要抓住线程模型这个关键点，所谓的疑难杂症都将迎刃而解。

2. Netty升级之后遭遇内存泄露

2.1. 问题描述

随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty4.X提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。

业务应用的特点是高并发、短流程，大多数对象都是朝生夕灭的短生命周期对象。为了减少内存的拷贝，用户期望在序列化的时候直接将对象编码到PooledByteBuf里，这样就不需要为每个业务消息都重新申请和释放内存。

业务的相关代码示例如下：

[java]
//在业务线程中初始化内存池分配器，分配非堆内存
ByteBufAllocator allocator = new PooledByteBufAllocator(true);
ByteBuf buffer = allocator.ioBuffer(1024);
//构造订购请求消息并赋值，业务逻辑省略
SubInfoReq infoReq = new SubInfoReq ();
infoReq.setXXX(……);
//将对象编码到ByteBuf中
codec.encode(buffer, info);
//调用ChannelHandlerContext进行消息发送
ctx.writeAndFlush(buffer);
[/java]

业务代码升级Netty版本并重构之后，运行一段时间，Java进程就会宕机，查看系统运行日志发现系统发生了内存泄露（示例堆栈）：

图2-1 OOM内存溢出堆栈

对内存进行监控（切换使用堆内存池，方便对内存进行监控），发现堆内存一直飙升，如下所示（示例堆内存监控）：

图2-2 堆内存监控

2.2. 问题定位

使用jmap -dump:format=b,file=netty.bin PID 将堆内存dump出来，通过IBM的HeapAnalyzer工具进行分析，发现ByteBuf发生了泄露。

因为使用了内存池，所以首先怀疑是不是申请的ByteBuf没有被释放导致？查看代码，发现消息发送完成之后，Netty底层已经调用ReferenceCountUtil.release(message)对内存进行了释放。这是怎么回事呢？难道Netty 4.X的内存池有Bug，调用release操作释放内存失败？

考虑到Netty 内存池自身Bug的可能性不大，首先从业务的使用方式入手分析：

内存的分配是在业务代码中进行，由于使用到了业务线程池做I/O操作和业务操作的隔离，实际上内存是在业务线程中分配的；
内存的释放操作是在outbound中进行，按照Netty 3的线程模型，downstream（对应Netty 4的outbound，Netty 4取消了upstream和downstream）的handler也是由业务调用者线程执行的，也就是说释放跟分配在同一个业务线程中进行。
初次排查并没有发现导致内存泄露的根因，一筹莫展之际开始查看Netty的内存池分配器PooledByteBufAllocator的Doc和源码实现，发现内存池实际是基于线程上下文实现的，相关代码如下：

[java]
final ThreadLocal<PoolThreadCache> threadCache = new ThreadLocal<PoolThreadCache>() {
private final AtomicInteger index = new AtomicInteger();
@Override
protected PoolThreadCache initialValue() {
final int idx = index.getAndIncrement();
final PoolArena<byte[]> heapArena;
final PoolArena<ByteBuffer> directArena;
if (heapArenas != null) {
heapArena = heapArenas[Math.abs(idx % heapArenas.length)];
} else {
heapArena = null;
}
if (directArenas != null) {
directArena = directArenas[Math.abs(idx % directArenas.length)];
} else {
directArena = null;
}
return new PoolThreadCache(heapArena, directArena);
}
[/java]

也就是说内存的申请和释放必须在同一线程上下文中，不能跨线程。跨线程之后实际操作的就不是同一块内存区域，这会导致很多严重的问题，内存泄露便是其中之一。内存在A线程申请，切换到B线程释放，实际是无法正确回收的。

通过对Netty内存池的源码分析，问题基本锁定。保险起见进行简单验证，通过对单条业务消息进行Debug，发现执行释放的果然不是业务线程，而是Netty的NioEventLoop线程：当某个消息被完全发送成功之后，会通过ReferenceCountUtil.release(message)方法释放已经发送成功的ByteBuf。

问题定位出来之后，继续溯源，发现Netty 4修改了Netty 3的线程模型：在Netty 3的时候，upstream是在I/O线程里执行的，而downstream是在业务线程里执行。当Netty从网络读取一个数据报投递给业务handler的时候，handler是在I/O线程里执行；而当我们在业务线程中调用write和writeAndFlush向网络发送消息的时候,handler是在业务线程里执行，直到最后一个Header handler将消息写入到发送队列中，业务线程才返回。

Netty4修改了这一模型，在Netty 4里inbound(对应Netty 3的upstream)和outbound(对应Netty 3的downstream)都是在NioEventLoop(I/O线程)中执行。当我们在业务线程里通过ChannelHandlerContext.write发送消息的时候，Netty 4在将消息发送事件调度到ChannelPipeline的时候，首先将待发送的消息封装成一个Task，然后放到NioEventLoop的任务队列中，由NioEventLoop线程异步执行。后续所有handler的调度和执行，包括消息的发送、I/O事件的通知，都由NioEventLoop线程负责处理。

下面我们分别通过对比Netty 3和Netty 4的消息接收和发送流程，来理解两个版本线程模型的差异：

Netty 3的I/O事件处理流程：

图2-3 Netty 3 I/O事件处理线程模型

Netty 4的I/O消息处理流程：

图2-4 Netty 4 I/O事件处理线程模型

2.3. 问题总结

Netty 4.X版本新增的内存池确实非常高效，但是如果使用不当则会导致各种严重的问题。诸如内存泄露这类问题，功能测试并没有异常，如果相关接口没有进行压测或者稳定性测试而直接上线，则会导致严重的线上问题。

内存池PooledByteBuf的使用建议：

申请之后一定要记得释放，Netty自身Socket读取和发送的ByteBuf系统会自动释放，用户不需要做二次释放；如果用户使用Netty的内存池在应用中做ByteBuf的对象池使用，则需要自己主动释放；
避免错误的释放：跨线程释放、重复释放等都是非法操作，要避免。特别是跨线程申请和释放，往往具有隐蔽性，问题定位难度较大；
防止隐式的申请和分配：之前曾经发生过一个案例，为了解决内存池跨线程申请和释放问题，有用户对内存池做了二次包装，以实现多线程操作时，内存始终由包装的管理线程申请和释放，这样可以屏蔽用户业务线程模型和访问方式的差异。谁知运行一段时间之后再次发生了内存泄露，最后发现原来调用ByteBuf的write操作时，如果内存容量不足，会自动进行容量扩展。扩展操作由业务线程执行，这就绕过了内存池管理线程，发生了“引用逃逸”。该Bug只有在ByteBuf容量动态扩展的时候才发生，因此，上线很长一段时间没有发生，直到某一天……因此，大家在使用Netty 4.X的内存池时要格外当心，特别是做二次封装时，一定要对内存池的实现细节有深刻的理解。
3. Netty升级之后遭遇数据被篡改

3.1. 问题描述

某业务产品，Netty3.X升级到4.X之后，系统运行过程中，偶现服务端发送给客户端的应答数据被莫名“篡改”。

业务服务端的处理流程如下：

将解码后的业务消息封装成Task，投递到后端的业务线程池中执行；
业务线程处理业务逻辑，完成之后构造应答消息发送给客户端；
业务应答消息的编码通过继承Netty的CodeC框架实现，即Encoder ChannelHandler;
调用Netty的消息发送接口之后，流程继续，根据业务场景，可能会继续操作原发送的业务对象。
业务相关代码示例如下：

[java]
//构造订购应答消息
SubInfoResp infoResp = new SubInfoResp();
//根据业务逻辑，对应答消息赋值
infoResp.setResultCode(0);
infoResp.setXXX()；
后续赋值操作省略……
//调用ChannelHandlerContext进行消息发送
ctx.writeAndFlush(infoResp);
//消息发送完成之后，后续根据业务流程进行分支处理，修改infoResp对象
infoResp.setXXX();
后续代码省略……
[/java]

3.2. 问题定位

首先对应答消息被非法“篡改”的原因进行分析，经过定位发现当发生问题时，被“篡改”的内容是调用writeAndFlush接口之后，由后续业务分支代码修改应答消息导致的。由于修改操作发生在writeAndFlush操作之后，按照Netty 3.X的线程模型不应该出现该问题。

在Netty3中，downstream是在业务线程里执行的，也就是说对SubInfoResp的编码操作是在业务线程中执行的，当编码后的ByteBuf对象被投递到消息发送队列之后，业务线程才会返回并继续执行后续的业务逻辑，此时修改应答消息是不会改变已完成编码的ByteBuf对象的，所以肯定不会出现应答消息被篡改的问题。

初步分析应该是由于线程模型发生变更导致的问题，随后查验了Netty 4的线程模型，果然发生了变化：当调用outbound向外发送消息的时候，Netty会将发送事件封装成Task，投递到NioEventLoop的任务队列中异步执行，相关代码如下：

[java]
@Override
public void invokeWrite(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {
if (msg == null) {
throw new NullPointerException("msg");
}
validatePromise(ctx, promise, true);
if (executor.inEventLoop()) {
invokeWriteNow(ctx, msg, promise);
} else {
AbstractChannel channel = (AbstractChannel) ctx.channel();
int size = channel.estimatorHandle().size(msg);
if (size > 0) {
ChannelOutboundBuffer buffer = channel.unsafe().outboundBuffer();
// Check for null as it may be set to null if the channel is closed already
if (buffer != null) {
buffer.incrementPendingOutboundBytes(size);
}
}
safeExecuteOutbound(WriteTask.newInstance(ctx, msg, size, promise), promise, msg);
}
}
[/java]

通过上述代码可以看出，Netty首先对当前的操作的线程进行判断，如果操作本身就是由NioEventLoop线程执行，则调用写操作；否则，执行线程安全的写操作，即将写事件封装成Task，放入到任务队列中由Netty的I/O线程执行，业务调用返回，流程继续执行。

通过源码分析，问题根源已经很清楚：系统升级到Netty 4之后，线程模型发生变化，响应消息的编码由NioEventLoop线程异步执行，业务线程返回。这时存在两种可能：

如果编码操作先于修改应答消息的业务逻辑执行，则运行结果正确；
如果编码操作在修改应答消息的业务逻辑之后执行，则运行结果错误。
由于线程的执行先后顺序无法预测，因此该问题隐藏的相当深。如果对Netty 4和Netty3的线程模型不了解，就会掉入陷阱。

Netty 3版本业务逻辑没有问题，流程如下：

图3-1 升级之前的业务流程线程模型

升级到Netty 4版本之后，业务流程由于Netty线程模型的变更而发生改变，导致业务逻辑发生问题：

图3-2 升级之后的业务处理流程发生改变

3.3. 问题总结

很多读者在进行Netty 版本升级的时候，只关注到了包路径、类和API的变更，并没有注意到隐藏在背后的“暗箭”- 线程模型变更。

升级到Netty 4的用户需要根据新的线程模型对已有的系统进行评估，重点需要关注outbound的ChannelHandler，如果它的正确性依赖于Netty 3的线程模型，则很可能在新的线程模型中出问题，可能是功能问题或者其它问题。

4. Netty升级之后性能严重下降

4.1. 问题描述

相信很多Netty用户都看过如下相关报告：

在Twitter，Netty 4 GC开销降为五分之一：Netty 3使用Java对象表示I/O事件，这样简单，但会产生大量的垃圾，尤其是在我们这样的规模下。Netty 4在新版本中对此做出了更改，取代生存周期短的事件对象，而以定义在生存周期长的通道对象上的方法处理I/O事件。它还有一个使用池的专用缓冲区分配器。

每当收到新信息或者用户发送信息到远程端，Netty 3均会创建一个新的堆缓冲区。这意味着，对应每一个新的缓冲区，都会有一个‘new byte[capacity]’。这些缓冲区会导致GC压力，并消耗内存带宽：为了安全起见，新的字节数组分配时会用零填充，这会消耗内存带宽。然而，用零填充的数组很可能会再次用实际的数据填充，这又会消耗同样的内存带宽。如果Java虚拟机（JVM）提供了创建新字节数组而又无需用零填充的方式，那么我们本来就可以将内存带宽消耗减少50%，但是目前没有那样一种方式。

在Netty 4中，代码定义了粒度更细的API，用来处理不同的事件类型，而不是创建事件对象。它还实现了一个新缓冲池，那是一个纯Java版本的 jemalloc （Facebook也在用）。现在，Netty不会再因为用零填充缓冲区而浪费内存带宽了。

我们比较了两个分别建立在Netty 3和4基础上echo协议服务器。（Echo非常简单，这样，任何垃圾的产生都是Netty的原因，而不是协议的原因）。我使它们服务于相同的分布式echo协议客户端，来自这些客户端的16384个并发连接重复发送256字节的随机负载，几乎使千兆以太网饱和。

根据测试结果，Netty 4：

GC中断频率是原来的1/5： 45.5 vs. 9.2次/分钟
垃圾生成速度是原来的1/5： 207.11 vs 41.81 MiB/秒
正是看到了相关的Netty 4性能提升报告，很多用户选择了升级。事后一些用户反馈Netty 4并没有跟产品带来预期的性能提升，有些甚至还发生了非常严重的性能下降，下面我们就以某业务产品的失败升级经历为案例，详细分析下导致性能下降的原因。

4.2. 问题定位

首先通过JMC等性能分析工具对性能热点进行分析，示例如下（信息安全等原因，只给出分析过程示例截图）：

图4-1 JMC性能监控分析

通过对热点方法的分析，发现在消息发送过程中，有两处热点：

消息发送性能统计相关Handler;
编码Handler。
对使用Netty 3版本的业务产品进行性能对比测试，发现上述两个Handler也是热点方法。既然都是热点，为啥切换到Netty4之后性能下降这么厉害呢？

通过方法的调用树分析发现了两个版本的差异：在Netty 3中，上述两个热点方法都是由业务线程负责执行；而在Netty 4中，则是由NioEventLoop(I/O)线程执行。对于某个链路，业务是拥有多个线程的线程池，而NioEventLoop只有一个，所以执行效率更低，返回给客户端的应答时延就大。时延增大之后，自然导致系统并发量降低，性能下降。

找出问题根因之后，针对Netty 4的线程模型对业务进行专项优化，性能达到预期，远超过了Netty 3老版本的性能。

Netty 3的业务线程调度模型图如下所示：充分利用了业务多线程并行编码和Handler处理的优势，周期T内可以处理N条业务消息。

图4-2 Netty 3业务调度性能模型

切换到Netty 4之后，业务耗时Handler被I/O线程串行执行，因此性能发生比较大的下降：

图4-3 Netty 4业务调度性能模型

4.3. 问题总结

该问题的根因还是由于Netty 4的线程模型变更引起，线程模型变更之后，不仅影响业务的功能，甚至对性能也会造成很大的影响。

对Netty的升级需要从功能、兼容性和性能等多个角度进行综合考虑，切不可只盯着API变更这个芝麻，而丢掉了性能这个西瓜。API的变更会导致编译错误，但是性能下降却隐藏于无形之中，稍不留意就会中招。

对于讲究快速交付、敏捷开发和灰度发布的互联网应用，升级的时候更应该要当心。

5. Netty升级之后上下文丢失

5.1. 问题描述

为了提升业务的二次定制能力，降低对接口的侵入性，业务使用线程变量进行消息上下文的传递。例如消息发送源地址信息、消息Id、会话Id等。

业务同时使用到了一些第三方开源容器，也提供了线程级变量上下文的能力。业务通过容器上下文获取第三方容器的系统变量信息。

升级到Netty 4之后，业务继承自Netty的ChannelHandler发生了空指针异常，无论是业务自定义的线程上下文、还是第三方容器的线程上下文，都获取不到传递的变量值。

5.2. 问题定位

首先检查代码，看业务是否传递了相关变量，确认业务传递之后怀疑跟Netty 版本升级相关，调试发现，业务ChannelHandler获取的线程上下文对象和之前业务传递的上下文不是同一个。这就说明执行ChannelHandler的线程跟处理业务的线程不是同一个线程！

查看Netty 4线程模型的相关Doc发现，Netty修改了outbound的线程模型，正好影响了业务消息发送时的线程上下文传递，最终导致线程变量丢失。

5.3. 问题总结

通常业务的线程模型有如下几种：

业务自定义线程池/线程组处理业务，例如使用JDK 1.5提供的ExecutorService；
使用J2EE Web容器自带的线程模型，常见的如JBoss和Tomcat的HTTP接入线程等；
隐式的使用其它第三方框架的线程模型，例如使用NIO框架进行协议处理，业务代码隐式使用的就是NIO框架的线程模型，除非业务明确的实现自定义线程模型。
在实践中我们发现很多业务使用了第三方框架，但是只熟悉API和功能，对线程模型并不清楚。某个类库由哪个线程调用，糊里糊涂。为了方便变量传递，又随意的使用线程变量，实际对背后第三方类库的线程模型产生了强依赖。当容器或者第三方类库升级之后，如果线程模型发生了变更，则原有功能就会发生问题。

鉴于此，在实际工作中，尽量不要强依赖第三方类库的线程模型，如果确实无法避免，则必须对它的线程模型有深入和清晰的了解。当第三方类库升级之后，需要检查线程模型是否发生变更，如果发生变化，相关的代码也需要考虑同步升级。

6. Netty3.X VS Netty4.X 之线程模型

通过对三个具有典型性的升级失败案例进行分析和总结，我们发现有个共性：都是线程模型改变惹的祸!

下面小节我们就详细得对Netty3和Netty4版本的I/O线程模型进行对比，以方便大家掌握两者的差异，在升级和使用中尽量少踩雷。

6.1 Netty 3.X 版本线程模型

Netty 3.X的I/O操作线程模型比较复杂，它的处理模型包括两部分：

Inbound：主要包括链路建立事件、链路激活事件、读事件、I/O异常事件、链路关闭事件等；
Outbound：主要包括写事件、连接事件、监听绑定事件、刷新事件等。
我们首先分析下Inbound操作的线程模型：

图6-1 Netty 3 Inbound操作线程模型

从上图可以看出，Inbound操作的主要处理流程如下：

I/O线程（Work线程）将消息从TCP缓冲区读取到SocketChannel的接收缓冲区中；
由I/O线程负责生成相应的事件，触发事件向上执行，调度到ChannelPipeline中；
I/O线程调度执行ChannelPipeline中Handler链的对应方法，直到业务实现的Last Handler;
Last Handler将消息封装成Runnable，放入到业务线程池中执行，I/O线程返回，继续读/写等I/O操作；
业务线程池从任务队列中弹出消息，并发执行业务逻辑。
通过对Netty 3的Inbound操作进行分析我们可以看出，Inbound的Handler都是由Netty的I/O Work线程负责执行。

下面我们继续分析Outbound操作的线程模型：

图6-2 Netty 3 Outbound操作线程模型

从上图可以看出，Outbound操作的主要处理流程如下：

业务线程发起Channel Write操作，发送消息；

Netty将写操作封装成写事件，触发事件向下传播；
写事件被调度到ChannelPipeline中，由业务线程按照Handler Chain串行调用支持Downstream事件的Channel Handler;
执行到系统最后一个ChannelHandler，将编码后的消息Push到发送队列中，业务线程返回；
Netty的I/O线程从发送消息队列中取出消息，调用SocketChannel的write方法进行消息发送。
6.2 Netty 4.X 版本线程模型

相比于Netty 3.X系列版本，Netty 4.X的I/O操作线程模型比较简答，它的原理图如下所示：

图6-3 Netty 4 Inbound和Outbound操作线程模型

从上图可以看出，Outbound操作的主要处理流程如下：

I/O线程NioEventLoop从SocketChannel中读取数据报，将ByteBuf投递到ChannelPipeline，触发ChannelRead事件；
I/O线程NioEventLoop调用ChannelHandler链，直到将消息投递到业务线程，然后I/O线程返回，继续后续的读写操作；
业务线程调用ChannelHandlerContext.write(Object msg)方法进行消息发送；
如果是由业务线程发起的写操作，ChannelHandlerInvoker将发送消息封装成Task，放入到I/O线程NioEventLoop的任务队列中，由NioEventLoop在循环中统一调度和执行。放入任务队列之后，业务线程返回；
I/O线程NioEventLoop调用ChannelHandler链，进行消息发送，处理Outbound事件，直到将消息放入发送队列，然后唤醒Selector，进而执行写操作。
通过流程分析，我们发现Netty 4修改了线程模型，无论是Inbound还是Outbound操作，统一由I/O线程NioEventLoop调度执行。

6.3. 线程模型对比

在进行新老版本线程模型PK之前，首先还是要熟悉下串行化设计的理念：

我们知道当系统在运行过程中，如果频繁的进行线程上下文切换，会带来额外的性能损耗。多线程并发执行某个业务流程，业务开发者还需要时刻对线程安全保持警惕，哪些数据可能会被并发修改，如何保护？这不仅降低了开发效率，也会带来额外的性能损耗。

为了解决上述问题，Netty 4采用了串行化设计理念，从消息的读取、编码以及后续Handler的执行，始终都由I/O线程NioEventLoop负责，这就意外着整个流程不会进行线程上下文的切换，数据也不会面临被并发修改的风险，对于用户而言，甚至不需要了解Netty的线程细节，这确实是个非常好的设计理念，它的工作原理图如下：

图6-4 Netty 4的串行化设计理念

一个NioEventLoop聚合了一个多路复用器Selector，因此可以处理成百上千的客户端连接，Netty的处理策略是每当有一个新的客户端接入，则从NioEventLoop线程组中顺序获取一个可用的NioEventLoop，当到达数组上限之后，重新返回到0，通过这种方式，可以基本保证各个NioEventLoop的负载均衡。一个客户端连接只注册到一个NioEventLoop上，这样就避免了多个I/O线程去并发操作它。

Netty通过串行化设计理念降低了用户的开发难度，提升了处理性能。利用线程组实现了多个串行化线程水平并行执行，线程之间并没有交集，这样既可以充分利用多核提升并行处理能力，同时避免了线程上下文的切换和并发保护带来的额外性能损耗。

了解完了Netty 4的串行化设计理念之后，我们继续看Netty 3线程模型存在的问题，总结起来，它的主要问题如下：

Inbound和Outbound实质都是I/O相关的操作，它们的线程模型竟然不统一，这给用户带来了更多的学习和使用成本；
Outbound操作由业务线程执行，通常业务会使用线程池并行处理业务消息，这就意味着在某一个时刻会有多个业务线程同时操作ChannelHandler，我们需要对ChannelHandler进行并发保护，通常需要加锁。如果同步块的范围不当，可能会导致严重的性能瓶颈，这对开发者的技能要求非常高，降低了开发效率；
Outbound操作过程中，例如消息编码异常，会产生Exception，它会被转换成Inbound的Exception并通知到ChannelPipeline，这就意味着业务线程发起了Inbound操作！它打破了Inbound操作由I/O线程操作的模型，如果开发者按照Inbound操作只会由一个I/O线程执行的约束进行设计，则会发生线程并发访问安全问题。由于该场景只在特定异常时发生，因此错误非常隐蔽！一旦在生产环境中发生此类线程并发问题，定位难度和成本都非常大。
讲了这么多，似乎Netty 4 完胜 Netty 3的线程模型，其实并不尽然。在特定的场景下，Netty 3的性能可能更高，就如本文第4章节所讲，如果编码和其它Outbound操作非常耗时，由多个业务线程并发执行，性能肯定高于单个NioEventLoop线程。

但是，这种性能优势不是不可逆转的，如果我们修改业务代码，将耗时的Handler操作前置，Outbound操作不做复杂业务逻辑处理，性能同样不输于Netty 3，但是考虑内存池优化、不会反复创建Event、不需要对Handler加锁等Netty 4的优化，整体性能Netty 4版本肯定会更高。

总而言之，如果用户真正熟悉并掌握了Netty 4的线程模型和功能类库，相信不仅仅开发会更加简单，性能也会更优！

6.4. 思考

就Netty 而言，掌握线程模型的重要性不亚于熟悉它的API和功能。很多时候我遇到的功能、性能等问题，都是由于缺乏对它线程模型和原理的理解导致的，结果我们就以讹传讹，认为Netty 4版本不如3好用等。

不能说所有开源软件的版本升级一定都胜过老版本，就Netty而言，我认为Netty 4版本相比于老的Netty 3，确实是历史的一大进步。