面试相关理论 写简历前看一遍 有用 有面试题 看3
写出学习新技术举例：学习pyhon一个月，引入什么框架设计，提高系统测试的覆盖率
70%提高到90%））
为了解决每秒上10亿的pv，采用了什么方法，什么技能
需要搜索
淘宝网日均pv在1千万左右，双12期间,购买率均超日常购买率;双12期间购买率高峰在0时,日常购买率高峰在10时以后,凌晨最低
阿里的开发手册中有条建议,单表行数超500万行或者单表容量超过2gb
-----
需要搜索
引起内存溢出的原因有很多种，常见的有以下几种：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据。
解决方法：检查对数据库查询中，是否有一次获得全部数据的查询；对于数据库查询尽量采用分页的方式查询。
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收。
解决方法：检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的
引用，使得这些对象不能被GC回收。
3.代码中存在死循环或循环产生过多重复的对象实体。
解决方法：检查代码中是否有死循环或递归调用；检查是否有大循环重复产生新对象实体。
4.使用的第三方软件中的BUG。
解决方法：使用内存查看工具动态查看内存使用情况。
5.启动参数内存值设定的过小；
解决方法：修改JVM启动参数(-Xms，-Xmx)，直接增加内存。
————————————————
OOM的常见情况：
第一类 堆栈溢出：java.lang.OutOfMemoryError: ......java heap space.....
也就是当你看到heap相关的时候就肯定是堆栈溢出了，此时如果代码没有问题的情况下，适当调整-Xmx和-Xms是可以避免的，不过一定是代码没有问题的前提，为什么会溢出呢，要么代码有问题，要么访问量太多并且每个访问的时间太长或者数据太多，导致数据释放不掉，因为垃圾回收器是要找到那些是垃圾才能回收，这里它不会认为这些东西是垃圾，自然不会去回收了；主意这个溢出之前，可能系统会提前先报错关键字为：
java.lang.OutOfMemoryError:GC over head limit exceeded
这种情况是当系统处于高频的GC状态，而且回收的效果依然不佳的情况，就会开始报这个错误，这种情况一般是产生了很多不可以被释放的对象，有可能是引用使用不当导致，或申请大对象导致，但是java heap space的内存溢出有可能提前不会报这个错误，也就是可能内存就直接不够导致，而不是高频GC.
第二类 PermGen的溢出：java.lang.OutOfMemoryError: PermGen space
系统的代码非常多或引用的第三方包非常多、或代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法，导致常量池的膨胀，虽然JDK 1.5以后可以通过设置对永久带进行回收，但是我们希望的是这个地方是不做GC的，它够用就行，所以一般情况下今年少做类似的操作，所以在面对这种情况常用的手段是：增加-XX:PermSize和-XX:MaxPermSize的大小。
第三类 在使用ByteBuffer中的allocateDirect()的时候会用到，很多javaNIO的框架中被封装为其他的方法：java.lang.OutOfMemoryError: Direct buffer memory
如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候，而不做clear的时候就会出现类似的问题，常规的引用程序IO输出存在一个内核态与用户态的转换过程，也就是对应直接内存与非直接内存，如果常规的应用程序你要将一个文件的内容输出到客户端需要通过OS的直接内存转换拷贝到程序的非直接内存（也就是heap中），然后再输出到直接内存由操作系统发送出去，而直接内存就是由OS和应用程序共同管理的，而非直接内存可以直接由应用程序自己控制的内存，jvm垃圾回收不会回收掉直接内存这部分的内存，所以要注意了哦。
如果经常有类似的操作，可以考虑设置参数：-XX:MaxDirectMemorySize
第四类：java.lang.StackOverflowError
这个参数直接说明一个内容，就是-Xss太小了，我们申请很多局部调用的栈针等内容是存放在用户当前所持有的线程中的，线程在jdk 1.4以前默认是256K，1.5以后是1M，如果报这个错，只能说明-Xss设置得太小，当然有些厂商的JVM不是这个参数，本文仅仅针对Hotspot VM而已；不过在有必要的情况下可以对系统做一些优化，使得-Xss的值是可用的。
第五类：java.lang.OutOfMemoryError: unable to create new native thread
上面第四种溢出错误，已经说明了线程的内存空间，其实线程基本只占用heap以外的内存区域，也就是这个错误说明除了heap以外的区域，无法为线程分配一块内存区域了，这个要么是内存本身就不够，要么heap的空间设置得太大了，导致了剩余的内存已经不多了，而由于线程本身要占用内存，所以就不够用了，说明了原因，如何去修改，不用我多说，你懂的。
第六类：java.lang.OutOfMemoryError: request {} byte for {}out of swap
这类错误一般是由于地址空间不够而导致。
---------------------------------------------------------------------------------------------------
六大类常见溢出已经说明JVM中99%的溢出情况，要逃出这些溢出情况非常困难，除非一些很怪异的故障问题会发生，比如由于物理内存的硬件问题，导致了code cache的错误（在由byte code转换为native code的过程中出现，但是概率极低），这种情况内存 会被直接crash掉，类似还有swap的频繁交互在部分系统中会导致系统直接被crash掉，OS地址空间不够的话，系统根本无法启动，呵呵；JNI的滥用也会导致一些本地内存无法释放的问题，所以尽量避开JNI；socket连接数据打开过多的socket也会报类似：IOException: Too many open files等错误信息。
垃圾识别机制
1.引用计数算法
引用计数算法是判断对象是否存活的算法之一：它给每一个对象加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能被使用的，即将被垃圾回收器回收。
缺点：
1.他需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
2.无法解决对象减互相循环引用的问题。即当两个对象循环引用时，引用计数器都为1，当对象周期结束后应该被回收却无法回收，造成内存泄漏。
2.可达性分析算法
目前主流使用的都是可达性分析算法来判断对象是否存活。算法基本思路：以“GC Roots”作为对象的起点,从此节点开始向下搜索，搜索所走过的路径成为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
哪些对象可作为GC Roots？
虚拟机栈（栈帧中的本地变量表）中引用的对象；
方法区中类静态属性引用的对象；
方法区中常量引用的对象；
本地方法栈中JNI（Native方法）引用的对象；
活跃线程的引用对象。
