附加整理2

MySQL主从复制与读写分离原理

主从复制可以实现读写分离

mysql优化的常用方法

索引的优化

• 只要列中含有NULL值，就最好不要在此例设置索引，复合索引如果有NULL值，此列在使用时也不会使用索引
• 尽量使用短索引，如果可以，应该制定一个前缀长度
• 对于经常在where子句使用的列，最好设置索引，这样会加快查找速度
• 对于有多个列where或者order by子句的，应该建立复合索引
• 对于like语句，以%或者‘-’开头的不会使用索引，以%结尾会使用索引
• 尽量不要在列上进行运算（函数操作和表达式操作）
• 尽量不要使用not in和<>操作

sql语句的优化

• 查询时，能不要*就不用*，尽量写全字段名
• 大部分情况连接效率远大于子查询
• 多使用explain和profile分析查询语句
• 查看慢查询日志，找出执行时间长的sql语句优化
• 多表连接时，尽量小表驱动大表，即小表 join 大表
• 在千万级分页时使用limit
• 对于经常使用的查询，可以开启缓存

3.表的优化

• 表的字段尽可能用NOT NULL
• 字段长度固定的表查询会更快
• 把数据库的大表按时间或一些标志分成小表
• 将表分区

git fetch和pull区别

因此，与git pull相比git fetch相当于是从远程获取最新版本到本地，但不会自动merge。如果需要有选择的合并git fetch是更好的选择。效果相同时git pull将更为快捷。（合并temp分支到本地的master分支）

JVM类加载时机

1、类加载时机   什么情况下虚拟机需要开始加载一个类呢？虚拟机规范中并没有对此进行强制约束，这点可以交给虚拟机的具体实现来自由把握。

2、类初始化时机 :遇到 new、getstatic、putstatic或invokestatic这四条字节码指令

这四条指令的最常见的Java代码场景是：

• 使用new关键字实例化对象的时候；

• 读取或设置一个类的静态字段（被final修饰，已在编译器把结果放入常量池的静态字段除外）的时候；

• 调用一个类的静态方法的时候。

注意： 

• 类的实例化是指创建一个类的实例(对象)的过程；
• 类的初始化是指为类中各个类成员(被static修饰的成员变量)赋初始值的过程，是类生命周期中的一个阶段。

重复类问题探究

本文要讨论的重复类是指类名和包名完全一样，并且不会被不同的类加载器分别加载的情况，也就是说这两个类只会有一个被加载到虚拟机中。

重复类可能引起的问题

重复类会被随机选择一个加载进去，加载完就不会加载另外一个同名重复类了

如果说两个重复类中的内容不一致，则很有可能在系统运行的时候会报错，比如报找不到某个方法的错(java.lang.NoSuchMethodError)。 

 

ArrayBlockingQueue和LinkedBlockingQueue的区别及使用

1. 队列中锁的实现不同

    ArrayBlockingQueue实现的队列中的锁是没有分离的，即生产和消费用的是同一个锁；

    LinkedBlockingQueue实现的队列中的锁是分离的，即生产用的是putLock，消费是takeLock

2. 在生产或消费时操作不同

    ArrayBlockingQueue实现的队列中在生产和消费的时候，是直接将枚举对象插入或移除的；

    LinkedBlockingQueue实现的队列中在生产和消费的时候，需要把枚举对象转换为Node进行插入或移除，会影响性能

3. 队列大小初始化方式不同

    ArrayBlockingQueue实现的队列中必须指定队列的大小；

    LinkedBlockingQueue实现的队列中可以不指定队列的大小，但是默认是Integer.MAX_VALUE

 

CAP定理和BASE理论

CAP定理

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：

　CAP原则是NOSQL数据库的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分区容错性）。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

一致性与可用性的决择

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

1、强一致性

这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大

2、弱一致性

这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态

3、最终一致性

最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

2、软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

 

四种线程池的使用

newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

- FixedThreadPool是一种容量固定的线程池； 
- 阻塞队列采用LinkedBlockingQueue，它是一种无界队列； 
- 由于阻塞队列是一个无界队列，因此永远不可能拒绝执行任务； 
- 由于采用无界队列，实际线程数将永远维持在nThreads，因此maximumPoolSize和keepAliveTime将无效。

 CachedThreadPool是一种可以无限扩容的线程池； 
- CachedThreadPool比较适合执行时间片比较小的任务； 
- keepAliveTime为60，意味着线程空闲时间超过60s就会被杀死； 
- 阻塞队列采用SynchronousQueue，这种阻塞队列没有存储空间，意味着只要有任务到来，就必须得有一个工作线程来处理，如果当前没有空闲线程，那么就再创建一个新的线程。

- ScheduledThreadPool接收SchduledFutureTask类型的任务，提交任务的方式有2种； 
1. scheduledAtFixedRate； 
2. scheduledWithFixedDelay； 
- SchduledFutureTask接收参数： 
time：任务开始时间 
sequenceNumber：任务序号 
period：任务执行的时间间隔 
- 阻塞队列采用DelayQueue，它是一种无界队列； 
- DelayQueue内部封装了一个PriorityQueue，它会根据time的先后排序，若time相同，则根据sequenceNumber排序； 
- 工作线程执行流程： 
1. 工作线程会从DelayQueue中取出已经到期的任务去执行； 
2. 执行结束后重新设置任务的到期时间，再次放回DelayQueue。

SynchronousQueue

1. SynchronousQueue没有容量。与其他BlockingQueue不同，SynchronousQueue是一个不存储元素的BlockingQueue。每一个put操作必须要等待一个take操作，否则不能继续添加元素，反之亦然。
2. 因为没有容量，所以对应 peek, contains, clear, isEmpty … 等方法其实是无效的。例如clear是不执行任何操作的，contains始终返回false,peek始终返回null。
3. SynchronousQueue分为公平和非公平，默认情况下采用非公平性访问策略，当然也可以通过构造函数来设置为公平性访问策略（为true即可）。
4. 若使用 TransferQueue, 则队列中永远会存在一个 dummy node（这点后面详细阐述）。

 

线程切换过程：

1.虚拟机启动之后，就进入了解释器的死循环，一直解释执行pc指针对应的java字节码。
2. 每个现在对应着一个stack，方面调用的时候，会在其上分配栈帧，由sp，fp等指针指向。
3. 线程调度，其实就是记录下当前线程的pc，sp，fp等寄存器指针，并将这几个指针（pc，sp，fp等，都是全局的）指向下一个将要执行的线程的相应位置。
4. 当恢复上述的几个指针之后，就切换回之前的线程了

 

二叉树的三种遍历非递归实现

package cn.it.cast.dao;

import java.util.Stack;
import java.util.HashMap;

public class BinTree{
    private char date;
    private BinTree lchild;
    private BinTree rchild;

    public BinTree(char c) {
        date = c;
    }

    // 先序遍历递归     
    public static void preOrder(BinTree t) {
        if (t == null) {
            return;
        }
        System.out.print(t.date);
        preOrder(t.lchild);
        preOrder(t.rchild);
    }

    // 中序遍历递归     
    public static void InOrder(BinTree t) {
        if (t == null) {
            return;
        }
        InOrder(t.lchild);
        System.out.print(t.date);
        InOrder(t.rchild);
    }

    // 后序遍历递归     
    public static void PostOrder(BinTree t) {
        if (t == null) {
            return;
        }
        PostOrder(t.lchild);
        PostOrder(t.rchild);
        System.out.print(t.date);
    }

    // 先序遍历非递归     
    public static void preOrder2(BinTree t) {
        Stack s = new Stack();
        while (t != null || !s.empty()) {
            while (t != null) {
                System.out.print(t.date);
                s.push(t);
                t = t.lchild;
            }
            if (!s.empty()) {
                t = s.pop();
                t = t.rchild;
            }
        }
    }

    // 中序遍历非递归     
    public static void InOrder2(BinTree t) {
        Stack s = new Stack();
        while (t != null || !s.empty()) {
            while (t != null) {
                s.push(t);
                t = t.lchild;
            }
            if (!s.empty()) {
                t = s.pop();
                System.out.print(t.date);
                t = t.rchild;
            }
        }
    }

    // 后序遍历非递归     
    public static void PostOrder2(BinTree t) {
        Stack s = new Stack();
        Stack s2 = new Stack();
        Integer i = new Integer(1);
        while (t != null || !s.empty()) {
            while (t != null) {
                s.push(t);
                s2.push(new Integer(0));
                t = t.lchild;
            }
            while (!s.empty() && s2.peek().equals(i)) {
                s2.pop();
                System.out.print(s.pop().date);
            }

            if (!s.empty()) {
                s2.pop();
                s2.push(new Integer(1));
                t = s.peek();
                t = t.rchild;
            }
        }
    }

    public static void main(String[] args) {
        BinTree b1 = new BinTree('a');
        BinTree b2 = new BinTree('b');
        BinTree b3 = new BinTree('c');
        BinTree b4 = new BinTree('d');
        BinTree b5 = new BinTree('e');

        /**
         *      a   
         *     / /  
         *    b   c  
         *   / /  
         *  d   e  
         */
        b1.lchild = b2;
        b1.rchild = b3;
        b2.lchild = b4;
        b2.rchild = b5;

        BinTree.preOrder(b1);
        System.out.println();
        BinTree.preOrder2(b1);
        System.out.println();
        BinTree.InOrder(b1);
        System.out.println();
        BinTree.InOrder2(b1);
        System.out.println();
        BinTree.PostOrder(b1);
        System.out.println();
        BinTree.PostOrder2(b1);
    }
}

 

Spring 框架中都用到了哪些设计模式

代理模式—在AOP和remoting中被用的比较多。

单例模式—在spring配置文件中定义的bean默认为单例模式。

模板方法—用来解决代码重复的问题 比如. RestTemplate, JmsTemplate, JpaTemplate。 前端控制器—Srping提供了DispatcherServlet来对请求进行分发。 视图帮助(View Helper )—Spring提供了一系列的JSP标签，高效宏来辅助将分散的代码整合在视图里。 依赖注入—贯穿于BeanFactory / ApplicationContext接口的核心理念。

工厂模式—BeanFactory用来创建对象的实例。

Builder模式- 自定义配置文件的解析bean是时采用builder模式，一步一步地构建一个beanDefinition

策略模式：Spring 中策略模式使用有多个地方，如 Bean 定义对象的创建以及代理对象的创建等。这里主要看一下代理对象创建的策略模式的实现。 前面已经了解 Spring 的代理方式有两个 Jdk 动态代理和 CGLIB 代理。这两个代理方式的使用正是使用了策略模式。

有1000个数据存在hashmap中，实际的数量是多少，考虑负载因子和扩容

我们有1000个元素new HashMap(1000), 但是理论上来讲new HashMap(1024)更合适，不过上面annegu已经说过，即使是1000，hashmap也自动会将其设置为1024。 但是new HashMap(1024)还不是更合适的，因为0.75*1000 < 1000, 也就是说为了让0.75 * size > 1000, 我们必须这样new HashMap(2048)才最合适

 

CHM在jdk1.8中主要做了2方面的改进

改进一：取消segments字段，直接采用transient volatile HashEntry[] table保存数据，采用table数组元素作为锁，从而实现了对每一行数据进行加锁，进一步减少并发冲突的概率。

改进二：将原先table数组＋单向链表的数据结构，变更为table数组＋单向链表＋红黑树的结构。对于hash表来说，最核心的能力在于将key hash之后能均匀的分布在数组中。如果hash之后散列的很均匀，那么table数组中的每个队列长度主要为0或者1。但实际情况并非总是如此理想，虽然ConcurrentHashMap类默认的加载因子为0.75，但是在数据量过大或者运气不佳的情况下，还是会存在一些队列长度过长的情况，如果还是采用单向列表方式，那么查询某个节点的时间复杂度为O(n)；因此，对于个数超过8(默认值)的列表，jdk1.8中采用了红黑树的结构，那么查询的时间复杂度可以降低到O(logN)，可以改进性能。

Redis和MySQL的区别

（1）类型上

从类型上来说，mysql是关系型数据库，redis是缓存数据库

（2）作用上

mysql用于持久化的存储数据到硬盘，功能强大，但是速度较慢

redis用于存储使用较为频繁的数据到缓存中，读取速度快

（3）需求上

mysql和redis因为需求的不同，一般都是配合使用。

如何保持MySQL和Redis的一致性？

1、分别处理

      针对某些对数据一致性要求不是特别高的情况下，可以将这些数据放入Redis，请求来了直接查询Redis，例如近期回复、历史排名这种实时性不强的业务。而针对那些强实时性的业务，例如虚拟货币、物品购买件数等等，则直接穿透Redis至MySQL上，等到MySQL上写入成功，再同步更新到Redis上去。这样既可以起到Redis的分流大量查询请求的作用，又保证了关键数据的一致性。

2、高并发情况下

       此时如果写入请求较多，则直接写入Redis中去，然后间隔一段时间，批量将所有的写入请求，刷新到MySQL中去；如果此时写入请求不多，则可以在每次写入Redis，都立刻将该命令同步至MySQL中去。这两种方法有利有弊，需要根据不同的场景来权衡。

  3、基于订阅binlog的同步机制（类似于mysql的主从复制）

       阿里巴巴的一款开源框架canal，提供了一种发布/ 订阅模式的同步机制，通过该框架我们可以对MySQL的binlog进行订阅，这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。值得注意的是，binlog需要手动打开，并且不会记录关于MySQL查询的命令和操作。

分布式系统session一致性问题

1.session复制

 应用服务器开启web容器的session复制功能，在集群中的几台服务器之间同步session对象，

多个web-server之间相互同步session，这样每个web-server之间都包含全部的session。

2. 客户端存储（cookie）

将session存储到浏览器cookie中。每次请求服务器的时候，将session放在请求中发送给服务器，服务器处理完请求后再将修改后的session响应给客户端。

3. 反向代理hash一致性（确保每个id每次访问一个节点）

反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个web-server上

4. 后端统一集中存储（即存储在数据库中）

将session存储在web-server后端的存储层，数据库或者缓存，一般用redis/memchachee缓存。

 

内存屏障（一个禁止指令重排序的cpu指令）

volatile语义中的内存屏障

• volatile的内存屏障策略非常严格保守，非常悲观且毫无安全感的心态：

在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；
在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；

• 由于内存屏障的作用，避免了volatile变量和其它指令重排序、线程之间实现了通信，使得volatile表现出了锁的特性。

mysql联合索引原理

非叶子节点是按照最左字段排序的，叶子点根据左边排序之后再顺序排序；解释了最左原则

Mysql行锁和表锁（针对不同的引擎来谈）

InnoDB有三种行锁的算法：

1，Record Lock：单个行记录上的锁。

2，Gap Lock：间隙锁，锁定一个范围，但不包括记录本身。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。

3，Next-Key Lock：1+2，锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。

 

因为InnoDB对于行的查询都是采用了Next-Key Lock的算法，锁定的不是单个值，而是一个范围（GAP）。上面索引值有1，3，5，8，11，其记录的GAP的区间如下：是一个左开右闭的空间（原因是默认主键的有序自增的特性，结合后面的例子说明）

（-∞,1]，(1,3]，(3,5]，(5,8]，(8,11]，(11,+∞）

特别需要注意的是，InnoDB存储引擎还会对辅助索引下一个键值加上gap lock。

例子 

+------+
| a    |
+------+
|    1 |
|    3 |
|    5 |
|    8 |
|   11 |
+------+

select * from t where a = 8 for update

该SQL语句锁定的范围是（5,8]，下个下个键值范围是（8,11]，所以插入5~11之间的值的时候都会被锁定，要求等待。即：插入5，6，7，8，9，10 会被锁住。插入非这个范围内的值都正常。

Mysql limit优化

1.子查询优化法
先找出第一条数据（即通过条件查询查询limit的第一条），然后大于等于这条数据的id就是要获取的数据

 select * from Member where MemberID >= (select MemberID from Member limit 1000,1) limit 100

3.反向查找优化法
当偏移超过一半记录数的时候，先用排序，这样偏移就反转了

 

MySQL 主从同步延迟的原因及解决办法

    a. 我们知道因为主服务器要负责更新操作， 他对安全性的要求比从服务器高， 所有有些设置可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 可以设置为0来提高sql的执行效率 这个能很大程度上提高效率。另外就是使用比主库更好的硬件设备作为slave。

    b. 就是把，一台从服务器当度作为备份使用， 而不提供查询， 那边他的负载下来了， 执行relay log 里面的SQL效率自然就高了。

    c. 增加从服务器喽，这个目的还是分散读的压力， 从而降低服务器负载。

 

i++的线程安全安全实现

1. 使用AtomicInteger，其中的 public final int getAndIncrement(){} 方法

2. 使用锁

 

java并发包

分布式锁的三种实现方式

基于数据库的实现方式

基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。

基于Redis的实现方式

选用Redis实现分布式锁原因：

（1）Redis有很高的性能；

（2）Redis命令对此支持较好，实现起来比较方便

基于ZooKeeper的实现方式

ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。

图的深度优先和广度优先遍历

图的深度优先搜索(Depth First Search)，和树的先序遍历比较类似。

它的思想：假设初始状态是图中所有顶点均未被访问，则从某个顶点v出发，首先访问该顶点，然后依次从它的各个未被访问的邻接点出发深度优先搜索遍历图，直至图中所有和v有路径相通的顶点都被访问到。 若此时尚有其他顶点未被访问到，则另选一个未被访问的顶点作起始点，重复上述过程，直至图中所有顶点都被访问到为止。

显然，深度优先搜索是一个递归的过程。

 

广度优先搜索算法(Breadth First Search)，又称为"宽度优先搜索"或"横向优先搜索"，简称BFS。

它的思想是：从图中某顶点v出发，在访问了v之后依次访问v的各个未曾访问过的邻接点，然后分别从这些邻接点出发依次访问它们的邻接点，并使得“先被访问的顶点的邻接点先于后被访问的顶点的邻接点被访问，直至图中所有已被访问的顶点的邻接点都被访问到。如果此时图中尚有顶点未被访问，则需要另选一个未曾被访问过的顶点作为新的起始点，重复上述过程，直至图中所有顶点都被访问到为止。

换句话说，广度优先搜索遍历图的过程是以v为起点，由近至远，依次访问和v有路径相通且路径长度为1,2...的顶点。

 

树的深度优先遍历需要用到额外的数据结构--->栈；

而广度优先遍历需要队列来辅助；这里以二叉树为例来实现 

    /**
     * 深度优先遍历，相当于先根遍历
     * 采用非递归实现
     * 需要辅助数据结构：栈
     */
    public void depthOrderTraversal(){
        if(root==null){
            System.out.println("empty tree");
            return;
        }
        ArrayDeque stack=new ArrayDeque();
        stack.push(root);
        while(stack.isEmpty()==false){
            TreeNode node=stack.pop();
            System.out.print(node.value+"    ");
            if(node.right!=null){
                stack.push(node.right);
            }
            if(node.left!=null){
                stack.push(node.left);
            }
        }
        System.out.print("\n");
    }

    public void levelOrderTraversal(){
        if(root==null){
            System.out.println("empty tree");
            return;
        }
        ArrayDeque queue=new ArrayDeque();
        queue.add(root);
        while(queue.isEmpty()==false){
            TreeNode node=queue.remove();
            System.out.print(node.value+"    ");
            if(node.left!=null){
                queue.add(node.left);
            }
            if(node.right!=null){
                queue.add(node.right);
            }
        }
        System.out.print("\n");
    }

 

HashSet与TreeSet对重复元素的判断不同之处

HashMap 的 put 与 HashSet 的 add  

于 HashSet 的 add() 方法添加集合元素时实际上转变为调用 HashMap 的 put() 方法来添加 key-value 对。HashMap 的 put() 方法首先调用.hashCode() 判断返回值相等，如果返回值相等则再通过 equals 比较也返回 true，最终认为key对象是相等的已经在HashMap中存在了。    

TreeMap 的 put 与 TreeSet 的 add

TreeMap中调用put方法添加键值时，调用对象的它的 compareTo（或 compare）方法对所有键进行比较，此方法饭回0，则认为两个键就是相等的。   TreeSet添加元素的时候，调用compareTo或compare方法来定位元素的位置，也就是返回compareTo或compare返回0则认为是同一个位置的元素，即相同元素

ArrayList动态扩容

/*
    *增加容量，以确保它至少能容纳
    *由最小容量参数指定的元素数。
    * @param mincapacity所需的最小容量
    */
    private void grow(int minCapacity) {
        // overflow-conscious code
        int oldCapacity = elementData.length;
        //>>位运算，右移动一位。 整体相当于newCapacity =oldCapacity + 0.5 * oldCapacity  
        // jdk1.7采用位运算比以前的计算方式更快
        int newCapacity = oldCapacity + (oldCapacity >> 1);
        if (newCapacity - minCapacity < 0)
            newCapacity = minCapacity;
       //jdk1.7这里增加了对元素个数的最大个数判断,jdk1.7以前是没有最大值判断的，MAX_ARRAY_SIZE 为int最大值减去8（不清楚为什么用这个值做比较）
        if (newCapacity - MAX_ARRAY_SIZE > 0)
            newCapacity = hugeCapacity(minCapacity);
        // 最重要的复制元素方法
        elementData = Arrays.copyOf(elementData, newCapacity);
    }

数据库的分库分表的一些总结(为了应对数据比较多的时候）

Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。

不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。

如果表并不多，但每张表的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库(server)上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。

二、数据库架构

1、简单的MySQL主从复制:

2、MySQL垂直分区： 如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。

3、MySQL水平分片（Sharding）：这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可

缓存穿透与缓存雪崩

缓存穿透

什么是缓存穿透？

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

 

如何避免？

1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。

2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。【感觉应该用的不多吧

 

缓存雪崩

什么是缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

如何避免？

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

2：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

3：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期（此点为补充）

 

缓存数据的淘汰

缓存淘汰的策略有两种：

(1) 定时去清理过期的缓存。

(2)当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。 

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂，具体用哪种方案，大家可以根据自己的应用场景来权衡。

 

1. 预估失效时间

2. 版本号（必须单调递增，时间戳是最好的选择）

3. 提供手动清理缓存的接口。

redis 学习笔记--hash表的渐进式rehash

redis采用渐进式rehash来解决这个问题。 何为渐进式rehash？

就是把拷贝节点数据的过程平摊到后续的操作中，而不是一次性拷贝。

所谓平摊到后续的操作中，就是对节点操作，例如再次插入，查找，删除，修改时都会进行拷贝。

要想实现这个过程，一个hash结构必须要有以下字段： 两个hash表。一个表拷贝到另一个表的容器 一个标识rehashidx来表明是否在进行rehash中。如果是，那么对节点的操作启动rehash过程。

以下是哈希表渐进式 rehash 的详细步骤：

为 ht[1] 分配空间， 让字典同时持有 ht[0] 和 ht[1] 两个哈希表。

在字典中维持一个索引计数器变量 rehashidx ， 并将它的值设置为 0 ， 表示 rehash 工作正式开始。

在 rehash 进行期间， 每次对字典执行添加、删除、查找或者更新操作时， 程序除了执行指定的操作以外， 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1] ， 当 rehash 工作完成之后， 程序将 rehashidx 属性的值增一。

随着字典操作的不断执行， 最终在某个时间点上， ht[0] 的所有键值对都会被 rehash 至 ht[1] ， 这时程序将 rehashidx 属性的值设为 -1， 表示 rehash 操作已完成。 

 

TreeMap底层是什么？（红黑树)

 

并行和并发的区别

你吃饭吃到一半，电话来了，你一直到吃完了以后才去接，这就说明你不支持并发也不支持并行。

你吃饭吃到一半，电话来了，你停了下来接了电话，接完后继续吃饭，这说明你支持并发。

你吃饭吃到一半，电话来了，你一边打电话一边吃饭，这说明你支持并行。

并发的关键是你有处理多个任务的能力，不一定要同时。 并行的关键是你有同时处理多个任务的能力。 所以我认为它们最关键的点就是：是否是『同时』。

做并发编程之前，必须首先理解什么是并发，什么是并行，什么是并发编程，什么是并行编程。 并发（concurrency）和并行（parallellism）是：

解释一：并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。

解释二：并行是在不同实体上的多个事件，并发是在同一实体上的多个事件。

解释三：在一台处理器上“同时”处理多个任务，在多台处理器上同时处理多个任务。如hadoop分布式集群 所以并发编程的目标是充分的利用处理器的每一个核，以达到最高的处理性能。

 

静态方法和实例方法的区别及使用场景

1、(静态)成员变量存放在data segment区（数据区），字符串常量也存放在该区

2、非静态变量，new出来的对象存放在堆内存，所有局部变量和引用地址存放在栈内存

3、方法（包括静态方法）存放在code segment(方法块),存放代码片段，且只存放一次 

 

网络七层及其协议

动态代理机制底层

1.动态代理可以由cglib/java Proxy/Aspectj/instrumentation等多种形式实现;

 

2.动态代理的本质是对class字节码进行动态构建或者修改;

a.修改的工具有ASM(= =比较难用,还是需要知道JVM指令)/javavssist(已经进行封装)

 

3.多种实现方式的区别在于对字节码切入方式不同.可选方式:

a.java代理/Cglib是基于动态构建接口实现类字节

b.AspectJ是借助eclipse工具在编译时织入代理字节

c.instrumentation是基于javaagent在类装载时,修改class织入代理字节

d.使用自定义classloader在装载时,织入代理字节

Spring bean 生命周期

   Spring上下文中的Bean也类似，如下

    1、实例化一个Bean－－也就是我们常说的new；

    2、按照Spring上下文对实例化的Bean进行配置－－也就是IOC注入；

    3、如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值

    4、如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；

    5、如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）；

    6、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；

    7、如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。

    8、如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法、；

    注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，这里我们不做赘述。

    9、当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；

    10、最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。

以上10步骤可以作为面试或者笔试的模板，另外我们这里描述的是应用Spring上下文Bean的生命周期，如果应用Spring的工厂也就是BeanFactory的话去掉第5步就Ok

 

完全二叉树与满二叉树的区别

 

平衡二叉树，是一种二叉排序树，其中每个结点的左子树和右子树的高度差至多等于1。它是一种高度平衡的二叉排序树。高度平衡？意思是说，要么它是一棵空树，要么它的左子树和右子树都是平衡二叉树，且左子树和右子树的深度之差的绝对值不超过1。

Java数据库连接库JDBC用到哪种设计模式?

桥接模式：

定义 ：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

意图 ：将抽象与实现解耦。

桥接模式所涉及的角色
1.  Abstraction ：定义抽象接口，拥有一个Implementor类型的对象引用
2.  RefinedAbstraction ：扩展Abstraction中的接口定义
3.  Implementor ：是具体实现的接口，Implementor和RefinedAbstraction接口并不一定完全一致，实际上这两个接口可以完全不一样Implementor提供具体操作方法，而Abstraction提供更高层次的调用
4.  ConcreteImplementor ：实现Implementor接口，给出具体实现

Jdk中的桥接模式：JDBC
JDBC连接 数据库 的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不动，原因就是JDBC提供了统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了

 

JDBC:Statement与PreparedStatement的联系与区别

使用PreparedStatement有几个好处 :       

1. 在执行可变参数的一条SQL时，PreparedStatement比Statement的效率高，因为DBMS预编译一条SQL当然会比多次编译一条SQL的效率要高。       

2. 安全性好，有效防止Sql注入等问题。       

3.对于多次重复执行的语句，使用PreparedStament效率会更高一点，并且在这种情况下也比较适合使用batch；       

4.代码的可读性和可维护性。

 

如何避免幻读

准备的理解是，当隔离级别是可重复读，且禁用innodb_locks_unsafe_for_binlog的情况下，在搜索和扫描index的时候使用的next-key locks可以避免幻读。

关键点在于，是InnoDB默认对一个普通的查询也会加next-key locks，还是说需要应用自己来加锁呢？如果单看这一句，可能会以为InnoDB对普通的查询也加了锁，如果是，那和序列化（SERIALIZABLE）的区别又在哪里呢？

我的理解是说，InnoDB提供了next-key locks，但需要应用程序自己去加锁。manual里提供一个例子：

SELECT * FROM child WHERE id > 100 FOR UPDATE;

这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。

可以使用show innodb status来查看是否给表加上了锁。

 

什么是MVCC？ 多版本并发控制。InnoDB为每行记录添加了一个版本号（系统版本号），每当修改数据时，版本号加一。 在读取事务开始时，系统会给事务一个当前版本号，事务会读取版本号<=当前版本号的数据，这时就算另一个事务插入一个数据，并立马提交，新插入这条数据的版本号会比读取事务的版本号高，因此读取事务读的数据还是不会变。

例如： 此时books表中有5条数据，版本号为1

事务A，系统版本号2：select * from books；因为1<=2所以此时会读取5条数据。

事务B，系统版本号3：insert into books ...，插入一条数据，新插入的数据版本号为3，而其他的数据的版本号仍然是2，插入完成之后commit，事务结束。

事务A，系统版本号2：再次select * from books；只能读取<=2的数据，事务B新插入的那条数据版本号为3，因此读不出来，解决了幻读的问题。

 

 

++num和num++哪个执行速度更快，++num为什么会比num++速度快

num++在执行过程中是需要经历两个过程的，首先是将num读到寄存器，再将num对应的内存地址的值进行加一操作，调用的时候是使用的是寄存器中的值，而不是直接用地址中的值。

++num在执行的时候是直接对num所对应的内存地址进行加一操作，调用的时候是直接使用该内存地址中的值进行操作。 所以在使用++num时速度会相对来说要快那么一点点。 

i=i+1与i+=1的区别及效率

 1.x=x+1,x+=1及x++的效率哪个最高？为什么？ x=x+1最低，因为它的执行如下。

（1）读取右x的地址；

（2）x+1；

（3）读取左x的地址；

（4）将右值传给左边的x（编译器并不认为左右x的地址相同）。

2. x+=1其次，它的执行如下。

（1）读取x的地址；

（2）x+1；

（3）将得到的值传给x（因为x的地址已经读出）。

3.   x++最高，它的执行如下。

（1）读取右x的地址；

（2）x自增1.

2.x=x+1,和 x+=1; 在什么情况下不成立 而且 x=x+1 是错误的; （类型隐式转换） short x=1; x+=1; x=x+1; //因为 x是 short 类型 .当它+1 会自动转变成int 当是等于又 是 short 类型..所以会报错;

3.x=x+1,和 x+=1; 在什么情况下不成立 而且 x+=1 是错误的; Object x=”abc”; String y=”def”; x+=y; x=x+y 

 

Collection与Collections的区别

Collection是集合类的上级接口，继承与他有关的接口主要有List和Set

Collections是针对集合类的一个帮助类，他提供一系列静态方法实现对各种集合的搜索、排序、线程安全等操作

Collections用法：

1） 排序（Sort） 使用sort方法可以根据元素的自然顺序 对指定列表按升序进行排序。列表中的所有元素都必须实现 Comparable 接口。此列表内的所有元素都必须是使用指定比较器可相互比较的 

2） 混排（Shuffling） 混排算法所做的正好与 sort 相反： 它打乱在一个 List 中可能有的任何排列的踪迹。也就是说，基于随机源的输入重排该 List，这样的排列具有相同的可能性（假设随机源是公正的）。这个算法在实现一个碰运气的游戏中是非常有用的。例如，它可被用来混排代表一副牌的 Card 对象的一个 List .另外，在生成测试案例时，它也是十分有用的。 

3） 反转（Reverse） 使用Reverse方法可以根据元素的自然顺序 对指定列表按降序进行排序。

4） 替换所有的元素（Fill） 使用指定元素替换指定列表中的所有元素。

5） 拷贝（Copy） 用两个参数，一个目标 List 和一个源 List， 将源的元素拷贝到目标，并覆盖它的内容。目标 List 至少与源一样长。如果它更长，则在目标 List 中的剩余元素不受影响。 Collections.copy（list，li）： 后面一个参数是目标列表 ，前一个是源列表

6） 返回Collections中最小元素（min） 根据指定比较器产生的顺序，返回给定 collection 的最小元素。collection 中的所有元素都必须是通过指定比较器可相互比较的 

7） 返回Collections中最大元素（max） 根据指定比较器产生的顺序，返回给定 collection 的最大元素。collection 中的所有元素都必须是通过指定比较器可相互比较的 

8） lastIndexOfSubList 返回指定源列表中最后一次出现指定目标列表的起始位置，即按从后到前的顺序返回子List在父List中的索引位置。 

11)static int binarySearch(List list,Object key)    使用二分搜索查找key对象的索引值，因为使用的二分查找，所以前提是必须有序。

12)static Object max(Collection coll)    根据元素自然顺序，返回集合中的最大元素

13)static Object max(Collection coll,Compare comp)    根据Comparator指定的顺序，返回给定集合中的最小元素

14)static Object min(Collection coll)    根据元素自然顺序，返回集合中的最大元素

15)static Object min(Collection coll,Compare comp)    根据Comparator指定的顺序，返回给定集合中的最小元素

16）static void fill(List list,Object obj)    使用指定元素替换指定集合中的所有元素

17）static int frequency(Collection c,Object o)    返回指定元素在集合中出现在次数

18）static int indexOfSubList(List source, List target)    返回子List对象在父List对象中第一次出现的位置索引； 如果父List中没有出现这样的子List，则返回-1

19）static int lastIndexOfSubList(List source,List target)    返回子List对象在父List对象中最后一次出现的位置索引，如果父List中没有出现这样的子List，刚返回-1

20）static boolean replaceAll(List list,Object oldVal,Object newVal)   使用一个新值newVal替换List对象所有旧值oldVal

21）synchronizedXXX(new XXX)       Collections类为集合类们提供的同步控制方法   

22)emptyXXX()    返回一个空的、不可变的集合对象，此处的集合既可以是List，也可以是Set,还可以是Map。

23）singletonXXX()    返回一个只包含指定对象（只有一个或一项元素）的、不可变的集合对象，此处集合既可以是List,也可以是Set,还可以是Map。

24）unmodificableXXX()    指定返回集合对象的不可变视图，此处的集合既可以是Lsit,也可以是Set,Map 

分布式环境下，怎么保证线程安全

避免并发

时间戳

串行化

数据库

行锁

统一触发途径

阻塞队列(BlockingQueue)的实现原理

在Java中，BlockingQueue是一个接口，它的实现类有ArrayBlockingQueue、DelayQueue、 LinkedBlockingDeque、LinkedBlockingQueue、PriorityBlockingQueue、SynchronousQueue等，它们的区别主要体现在存储结构上或对元素操作上的不同，但是对于take与put操作的原理，却是类似的。下面的源码以ArrayBlockingQueue为例。

BlockingQueue内部有一个ReentrantLock，其生成了两个Condition

可以看见，put(E)与take()是同步的，在put操作中，当队列满了，会阻塞put操作，直到队列中有空闲的位置。而在take操作中，当队列为空时，会阻塞take操作，直到队列中有新的元素。 而这里使用两个Condition，则可以避免调用signal()时，会唤醒相同的put或take操作。 

1. add()：队列已满时，再添加会抛出异常——对应remove()
2. offer()：添加元素后，会返回一个boolean值，看是否添加成功。若队列已满，再添加不会抛异常，但是返回false,表示添加失败——对应poll()
3. put()：队列已满，再添加会阻塞——对应take()

Redis的setnx都是原子性操作

 

使用SETNX实现分布式锁 

MySQL从其他数据表或者查询结果中创建数据表

从其他数据表中创建数据表，可以使用如下命令： create table ... like ...

1 该语句将创建一个新的数据表作为原始数据表的一份空白副本。

它将把原始数据表的所有列属性都会一摸一样的复制过来，但是数据表的内容是空的。如果我们想填充它，可以使用如下命令: Insert into .. select .. 

 

从查询结果中创建数据表 使用如下命令，从一个select语句中创建新的数据表。

create table ... select ...

1 该语句优点是不仅仅创建了数据表，还复制了数据表中的数据。缺点是该语句不会复制所有的数据 列属性，如索引、auto_increment等。因为结果集本身就不带索引等。

海量数据排序——如果有1TB的数据需要排序，但只有32GB的内存如何排序处理？

1、外排序 

外排序采用分块的方法（分而治之），首先将数据分块，对块内数据按选择一种高效的内排序策略进行排序。然后采用归并排序的思想对于所有的块进行排序，得到所有数据的一个有序序列 

例如，考虑一个1G文件，可用内存100M的排序方法。首先将文件分成10个100M，并依次载入内存中进行排序，最后结果存入硬盘。得到的是10个分别排序的文件。接着从每个文件载入9M的数据到输入缓存区，输出缓存区大小为10M。对输入缓存区的数据进行归并排序，输出缓存区写满之后写在硬盘上，缓存区清空继续写接下来的数据。对于输入缓存区，当一个块的9M数据全部使用完，载入该块接下来的9M数据，一直到所有的9个块的所有数据都已经被载入到内存中被处理过。最后我们得到的是一个1G的排序好的存在硬盘上的文件。

合理设置线程池大小

 

任务的性质：

CPU密集型任务、IO密集型任务、混合型任务。

任务的优先级：高、中、低。

任务的执行时间：长、中、短。

任务的依赖性：是否依赖其他系统资源，如数据库连接等。

若任务对其他系统资源有依赖，如某个任务依赖数据库的连接返回的结果，这时候等待的时间越长，则CPU空闲的时间越长，那么线程数量应设置得越大，才能更好的利用CPU。 当然具体合理线程池值大小，需要结合系统实际情况，在大量的尝试下比较才能得出，以上只是前人总结的规律。 

最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目 

可以得出一个结论： 线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程。 以上公式与之前的CPU和IO密集型任务设置线程数基本吻合。

并发编程网上的一个问题 高并发、任务执行时间短的业务怎样使用线程池？并发不高、任务执行时间长的业务怎样使用线程池？并发高、业务执行时间长的业务怎样使用线程池？

（1）高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换 （2）并发不高、任务执行时间长的业务要区分开看： 　　

         a）假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以适当加大线程池中的线程数目，让CPU处理更多的业务 　　

         b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换

（3）并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，增加服务器是第二步，至于线程池的设置，设置参考（2）。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件对任务进行拆分和解耦。

 

CMS 垃圾回收（比之前记的多了两个阶段）

初始标记 ：在这个阶段，需要虚拟机停顿正在执行的任务，官方的叫法STW(Stop The Word)。这个过程从垃圾回收的”根对象”开始，只扫描到能够和”根对象”直接关联的对象，并作标记。所以这个过程虽然暂停了整个JVM，但是很快就完成了。

并发标记 ：这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记。并发标记阶段，应用程序的线程和并发标记的线程并发执行，所以用户不会感受到停顿。

并发预清理 ：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代， 或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段”重新标记”的工作，因为下一个阶段会Stop The World。

重新标记 ：这个阶段会暂停虚拟机，收集器线程扫描在CMS堆中剩余的对象。扫描从”跟对象”开始向下追溯，并处理对象关联。

并发清理 ：清理垃圾对象，这个阶段收集器线程和应用程序线程并发执行。

并发重置 ：这个阶段，重置CMS收集器的数据结构，等待下一次垃圾回收。 

 

BitMap

一个byte是占8个bit，如果每一个bit的值就是有或者没有，也就是二进制的0或者1，如果用bit的位置代表数组值有还是没有，那么0代表该数值没有出现过，1代表该数组值出现过。不也能描述数据了吗？如下图：

是不是很神奇，那么现在假如10亿的数据所需的空间就是3.72G/32了吧，一个占用32bit的数据现在只占用了1bit，节省了不少的空间，排序就更不用说了，一切显得那么顺利。这样的数据之间没有关联性，要是读取的，你可以用多线程的方式去读取。时间复杂度方面也是O(Max/n)，其中Max为byte[]数组的大小，n为线程大小。

硬中断和软中断

硬中断和软中断的区别 软中断是执行中断指令产生的，而硬中断是由外设引发的。

硬中断的中断号是由中断控制器提供的，软中断的中断号由指令直接指出，无需使用中断控制器。

硬中断是可屏蔽的，软中断不可屏蔽。 硬中断处理程序要确保它能快速地完成任务，这样程序执行时才不会等待较长时间，称为上半部。

软中断处理硬中断未完成的工作，是一种推后执行的机制，属于下半部。   

 

匿名内部类 是否可以继承其它类，是否可以实现接口

可以继承其他类或实现其他接口

equals的默认实现(直接比较两者的引用）

IOC的实现原理—反射与工厂模式

       我们可以把IOC容器的工作模式看做是工厂模式的升华，可以把IOC容器看作是一个工厂，这个工厂里要生产的对象都在配置文件中给出定义，然后利用编程语言提供的反射机制，根据配置文件中给出的类名生成相应的对象。从实现来看，IOC是把以前在工厂方法里写死的对象生成代码，改变为由配置文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。 

Java中反射的实现方式

 

第一种：通过Object类的getClass方法       Class cla = foo.getClass();

第二种：通过对象实例方法获取对象          Class cla = foo.class();

第三种：通过Class.forName方式              Class cla = Class.forName("xx.xx.Foo")

 

Spring框架中，一旦把一个Bean纳入Spring IOC容器之中，这个Bean的生命周期就会交由容器进行管理，一般担当管理角色的是BeanFactory或者ApplicationContext,

 

二叉树除了用链表还能用数组表示。

 

Static 静态类

1.静态内部类跟静态方法一样，只能访问静态的成员变量和方法，不能访问非静态的方法和属性，但是普通内部类可以访问任意外部类的成员变量和方法

2.静态内部类可以声明普通成员变量和方法，而普通内部类不能声明static成员变量和方法。

3.静态内部类可以单独初始化: 

静态内部类使用场景一般是当外部类需要使用内部类，而内部类无需外部类资源，并且内部类可以单独创建的时候会考虑采用静态内部类的设计.

分布式事务中2PC与3PC的区别

2PC

2PC，也就是两段提交：

1）第一阶段参与值接收到开始事务的请求之后，返回accept或者abort，如果返回accept，就预先执行事务，并记录相关的日志和undo。

2）第二阶段coordinator发起commit，participant接受后返回commit或者abort。

第二阶段协调者和参与者挂了，挂了的这个参与者在挂之前已经执行了操作。但是由于他挂了，没有人知道他执行了什么操作。 这种情况下，新的协调者被选出来之后，如果他想负起协调者的责任的话他就只能按照之前那种情况来执行commit或者roolback操作。这样新的协调者和所有没挂掉的参与者就保持了数据的一致性，我们假定他们执行了commit。

但是，这个时候，那个挂掉的参与者恢复了怎么办，因为他之前已经执行完了之前的事务，如果他执行的是commit那还好，和其他的机器保持一致了，万一他执行的是roolback操作那？这不就导致数据的不一致性了么？虽然这个时候可以再通过手段让他和协调者通信，再想办法把数据搞成一致的，但是，这段时间内他的数据状态已经是不一致的了！

3PC

3PC，是三段提交：

1）第一阶段接受到开始事务的请求之后，根据participant的情况，返回accpert或者abort。

2）第二阶段coordinator发起pre-commit请求，participant prepare to commit或者abort或者超时commit，commit即会执行事务，并记录相关的日志和undo。

3）第三阶段coordinator发起commit请求，participant commit或者abort或者超时commit。

 

所以，2PC协议中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。 为了解决这个问题，衍生除了3PC。我们接下来看看3PC是如何解决这个问题的。

3PC最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。在第一阶段，只是询问所有参与者是否可可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

简单概括一下就是，如果挂掉的那台机器已经执行了commit，那么协调者可以从所有未挂掉的参与者的状态中分析出来，并执行commit。如果挂掉的那个参与者执行了rollback，那么协调者和其他的参与者执行的肯定也是rollback操作。 所以，再多引入一个阶段之后，3PC解决了2PC中存在的那种由于协调者和参与者同时挂掉有可能导致的数据一致性问题。

3PC存在的问题 在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。 所以，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。 

单链表的两种实现方式

第一种： 递归

static Node reverseLinkedList(Node node) {
    if (node == null || node.next == null) {
        return node;
    } else {
        Node headNode = reverseLinkedList(node.next);
        node.next.next = node;
        node.next = null;
        return headNode;
    }
}

第二种： 遍历

static Node reverseLinkedList(Node node) {
    Node previousNode = null;
    Node currentNode = node;
    Node headNode = null;
    while (currentNode != null) {
        Node nextNode = currentNode.next;
        if (nextNode == null) {
            headNode = currentNode;
        }
        currentNode.next = previousNode;
        previousNode = currentNode;
        currentNode = nextNode;
    }
    return headNode;
}

缓存--基于linkedHashMap实现LRU缓存淘汰策略

LinkedHashMap 内部也有维护一个双向队列，在初始化时也会给定一个缓存大小的阈值。初始化时自定义是否需要删除最近不常使用的数据，如果是则会按照实现二中的方式管理数据。

其实主要代码就是重写了 LinkedHashMap 的 removeEldestEntry 方法:

protected boolean removeEldestEntry(Map.Entry eldest) {
        return false;
    }

package LinkedHashMap实现LRU;
 
import java.util.ArrayList;
import java.util.Collection;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.Map.Entry;
 
public class LRULinkedMap {
 
	/**
     * 最大缓存大小
     */
	private int cacheSize;
	
	private LinkedHashMap cacheMap;
	
	public LRULinkedMap(int cacheSize){
		this.cacheSize = cacheSize;
		
		cacheMap = new LinkedHashMap(16, 0.75F, true){
 
			@Override
			protected boolean removeEldestEntry(Entry eldest) {
				if(cacheSize + 1 == cacheMap.size()){
					return true;
				}else{
					return false;
				}
			}
		};
	}
	
	public void put(K key, V value){
		cacheMap.put(key, value);
	}
	
	public V get(K key){
		return cacheMap.get(key);
	}
	
	public Collection> getAll(){
		return new ArrayList>(cacheMap.entrySet());
	}
	
	public static void main(String[] args) {
		LRULinkedMap map = new LRULinkedMap<>(3);
		map.put("key1", 1);
		map.put("key2", 2);
		map.put("key3", 3);
		
		for (Map.Entry e : map.getAll()){
			System.out.println(e.getKey()+"====>"+e.getValue());
		}
		System.out.println("\n");
		map.put("key4", 4);
		for (Map.Entry e : map.getAll()){
			System.out.println(e.getKey()+"====>"+e.getValue());
		}
		
	}
	 
}

final方法不能被覆盖,可被重载(方法名相同而参数不同)

finalize 方法

之所以要使用finalize()，是存在着垃圾回收器不能处理的特殊情况。假定你的对象（并非使用new方法）获得了一块“特殊”的内存区域，由于垃圾回收器只知道那些显示地经由new分配的内存空间，所以它不知道该如何释放这块“特殊”的内存区域，那么这个时候java允许在类中定义一个由finalize()方法。

      特殊的区域例如：

1）由于在分配内存的时候可能采用了类似 C语言的做法，而非JAVA的通常new做法。这种情况主要发生在native method中，比如native method调用了C/C++方法malloc()函数系列来分配存储空间，但是除非调用free()函数，否则这些内存空间将不会得到释放，那么这个时候就可能造成内存泄漏。但是由于free()方法是在C/C++中的函数，所以finalize()中可以用本地方法来调用它。以释放这些“特殊”的内存空间。

2）又或者打开的文件资源，这些资源不属于垃圾回收器的回收范围。

tcp连接之半连接攻击和全连接攻击总结

半连接就是通过不断地构造客户端的SYN连接数据包发向服务端，等到服务端的半连接队列满的时候，后续的正常用户的连接请求将会被丢弃，从而无法连接到服务端。此为半连接攻击方式。根据服务端的半连接队列的大小，不同主机的抵抗这种SYN攻击的能力也是不一样。

可以通过拓展半连接队列的大小，来进行补救，但缺点是，不能无限制的增加，这样会耗费过多的服务端资源，导致服务端性能地下。这种方式几乎不可取。现主要通syn cookie或者syn中继机制来防范半连接攻，部位半连接分配核心内存的方式来防范。

   全连接攻击是通过消费服务端进程数和连接数，只连接而不进行发送数据的一种攻击方式。当客户端连接到服务端，仅仅只是连接，此时服务端会为每一个连接创建一个进程来处理客户端发送的数据。但是客户端只是连接而不发送数据，此时服务端会一直阻塞在recv或者read的状态，如此一来，多个连接，服务端的每个连接都是出于阻塞状态从而导致服务端的崩溃。 

可以通过不为全连接分配进程处理的方式来防范全连接攻击，具体的情况是当收到数据之后，在为其分配一个处理线程。具体的处理方式在accept返回之前是不分配处理线程的。直到接收相关的数据之后才为之提供一个处理过程。

submit 和 execute的区别

execute(Runnable x) 没有返回值。可以执行任务，但无法判断任务是否成功完成。——实现Runnable接口
submit(Runnable x) 返回一个future。可以用这个future来判断任务是否成功完成。——实现Callable接口

多线程中Future与FutureTask的区别和联系

    Future submit(Callable task);  
    Future submit(Runnable task, T result);  
    Future submit(Runnable task);  
 

第一个方法：submit提交一个实现Callable接口的任务，并且返回封装了异步计算结果的Future。

第二个方法：submit提交一个实现Runnable接口的任务，并且指定了在调用Future的get方法时返回的result对象。（不常用）

第三个方法：submit提交一个实现Runnable接口的任务，并且返回封装了异步计算结果的Future。
因此我们只要创建好我们的线程对象（实现Callable接口或者Runnable接口），然后通过上面3个方法提交给线程池去执行即可。还有点要注意的是，除了我们自己实现Callable对象外，我们还可以使用工厂类Executors来把一个Runnable对象包装成Callable对象。Executors工厂类提供的方法如下：
 

interrupt(),isInterrupted()和interrupted()

① interrupt():中断本线程
myThread.interrupt();//中断的是调用interrupt()方法的线程
小结：阻塞于wait/join/sleep的线程，中断状态会被清除掉，同时收到著名的InterruptedException；而其他情况中断状态都被设置，并不一定收到异常。

② isInterrupted():检测本线程是否已经中断
myThread.isInterrupted();//判断本线程myThread是否中断
如果已经中断，则返回true，否则false。中断状态不受该方法的影响。
如果中断调用时线程已经不处于活动状态，则返回false。

③ interrupted():检测当前线程是否已经中断
Thread.interrupted();//判断该语句所在线程是否中断
如果已经中断，则返回true，否则false，并清除中断状态。换言之，如果该方法被连续调用两次，第二次必将返回false，除非在第一次与第二次的瞬间线程再次被中断。
如果中断调用时线程已经不处于活动状态，则返回false。

 

父类引用指向子类对象

我们可以看到多态中的成员访问特点：

• 成员变量
  • 编译看左边，运行看左边
• 构造方法
  • 子类的构造都会默认访问父类构造
• 成员方法
  • 编译看左边，运行看右边
• 静态方法
  • 编译看左边，运行看左边
  • 所以静态方法不能算方法的重写

 

Java内存使用情况查看工具

一、jstat查看 gc实时执行情况

二、jmap查看各个代的内存使用

三、jstack和 jinfo分析java core文件

四、jstack查看进程所包含的线程情况.

五、jps查看当前系统Java运行的进程PID

 

数据库冗余的利与弊？

在设计数据库时，某一字段属于一个表，但它又同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段。

1，尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、优雅、让人心醉。

2，合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。

（即空间和时间的转换关系）

 

关于AOP无法切入同类调用方法的问题

一个类有a，b两个方法，a中调用了b，如果用动态代理拦截了b，那么调用a方法时，a中对b调用会被拦截么？

public class Bean1 implements Bean {
    public void a() {System.out.println('a');b();}
    public void b() {System.out.println('b');}
}
 
public class Test implements InvocationHandler {
    public Bean bean;
    public Test(Bean bean) {this.bean = bean;}
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.getName().equals('b')) {
           System.out.println('c');
        }
        return method.invoke(bean, args);
}
    public static void main(String[] args) {
        Bean b = new Bean1();
        Test t = new Test(b);
        Bean proxy = (Bean) Proxy.newProxyInstance(Test.class.getClassLoader(), new Class[] { Bean.class }, t);
        proxy.a();
        proxy.b();
    }
}

上述代码创建了Bean1的实例b的代理，拦截Bean上的b()方法，执行该方法前打印出 ‘c’。但调用proxy.a()方法并不会打印出c，只打印了a，和b。直接调用proxy.b()则会打印出c和b。

 

Java中创建（实例化）对象的五种方式
1、用new语句创建对象，这是最常见的创建对象的方法。

2、通过工厂方法返回对象，如：String str = String.valueOf(23); 
3、运用反射手段,调用java.lang.Class或者java.lang.reflect.Constructor类的newInstance()实例方法。如：Object obj = Class.forName("java.lang.Object").newInstance(); 
4、调用对象的clone()方法。
5、通过I/O流（包括反序列化），如运用反序列化手段，调用java.io.ObjectInputStream对象的 readObject()方法。

 

innodb中mvcc的理解

MVCC（Multi-Version Concurrency Control）即多版本并发控制。
MySQL的大多数事务型（如InnoDB,Falcon等）存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，他们一般都同时实现了MVCC。当前不仅仅是MySQL,其它数据库系统（如Oracle,PostgreSQL）也都实现了MVCC。值得注意的是MVCC并没有一个统一的实现标准，所以不同的数据库，不同的存储引擎的实现都不尽相同。

MVCC优缺点

MVCC在大多数情况下代替了行锁，实现了对读的非阻塞，读不加锁，读写不冲突。缺点是每行记录都需要额外的存储空间，需要做更多的行维护和检查工作。

可以解决幻读的问题

MVCC的实现原理

undo log

为了便于理解MVCC的实现原理，这里简单介绍一下undo log的工作过程

在不考虑redo log 的情况下利用undo log工作的简化过程为：

序号	动作
1	开始事务
2	记录数据行数据快照到undo log
3	更新数据
4	将undo log写到磁盘
5	将数据写到磁盘
6	提交事务

1）为了保证数据的持久性数据要在事务提交之前持久化
2）undo log的持久化必须在在数据持久化之前，这样才能保证系统崩溃时，可以用undo log来回滚事务

Innodb中的隐藏列

Innodb通过undo log保存了已更改行的旧版本的信息的快照。
InnoDB的内部实现中为每一行数据增加了三个隐藏列用于实现MVCC。

列名	长度(字节)	作用
DB_TRX_ID	6	插入或更新行的最后一个事务的事务标识符。（删除视为更新，将其标记为已删除）
DB_ROLL_PTR	7	写入回滚段的撤消日志记录（若行已更新，则撤消日志记录包含在更新行之前重建行内容所需的信息）
DB_ROW_ID	6	行标识（隐藏单调自增id）

结构

MVCC工作过程

MVCC只在READ COMMITED 和 REPEATABLE READ 两个隔离级别下工作。READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE 则会对所有读取的行都加锁

SELECT

InnoDB 会根据两个条件来检查每行记录：

• InnoDB只查找版本(DB_TRX_ID)早于当前事务版本的数据行（行的系统版本号<=事务的系统版本号,这样可以确保数据行要么是在开始之前已经存在了，要么是事务自身插入或修改过的）
• 行的删除版本号(DB_ROLL_PTR)要么未定义（未更新过），要么大于当前事务版本号（在当前事务开始之后更新的）。这样可以确保事务读取到的行，在事务开始之前未被删除。

INSERT

InnoDB为新插入的每一行保存当前系统版本号作为行版本号

DELETE

InnoDB为删除的每一行保存当前的系统版本号作为行删除标识

UPDATE

InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识

1.3 MVCC实现

MVCC是通过保存数据在某个时间点的快照来实现的. 不同存储引擎的MVCC. 不同存储引擎的MVCC实现是不同的,典型的有乐观并发控制和悲观并发控制.

MVCC 具体实现分析

下面,我们通过InnoDB的MVCC实现来分析MVCC使怎样进行并发控制的.
InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的,这两个列，分别保存了这个行的创建时间，一个保存的是行的删除时间。这里存储的并不是实际的时间值,而是系统版本号(可以理解为事务的ID)，没开始一个新的事务，系统版本号就会自动递增，事务开始时刻的系统版本号会作为事务的ID.下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操作的.

 

假设1

假设在执行这个事务ID为2的过程中,刚执行到(1),这时,有另一个事务ID为3往这个表里插入了一条数据;
第三个事务ID为3;

start transaction;
insert into yang values(NULL,'tian');
commit;

• 1
• 2
• 3

这时表中的数据如下:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

然后接着执行事务2中的(2),由于id=4的数据的创建时间(事务ID为3),执行当前事务的ID为2,而InnoDB只会查找事务ID小于等于当前事务ID的数据行,所以id=4的数据行并不会在执行事务2中的(2)被检索出来,在事务2中的两条select 语句检索出来的数据都只会下表:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	undefined
2	long	1	undefined
3	fei	1	undefined

假设2

假设在执行这个事务ID为2的过程中,刚执行到(1),假设事务执行完事务3后，接着又执行了事务4;
第四个事务:

start   transaction;  
delete from yang where id=1;
commit;  

• 1
• 2
• 3

此时数据库中的表如下:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	undefined
3	fei	1	undefined
4	tian	3	undefined

接着执行事务ID为2的事务(2),根据SELECT 检索条件可以知道,它会检索创建时间(创建事务的ID)小于当前事务ID的行和删除时间(删除事务的ID)大于当前事务的行,而id=4的行上面已经说过,而id=1的行由于删除时间(删除事务的ID)大于当前事务的ID,所以事务2的(2)select * from yang也会把id=1的数据检索出来.所以,事务2中的两条select 语句检索出来的数据都如下:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	undefined
3	fei	1	undefined

UPDATE

InnoDB执行UPDATE，实际上是新插入了一行记录，并保存其创建时间为当前事务的ID，同时保存当前事务ID到要UPDATE的行的删除时间.

假设3

假设在执行完事务2的(1)后又执行,其它用户执行了事务3,4,这时，又有一个用户对这张表执行了UPDATE操作:
第5个事务:

start  transaction;
update yang set name='Long' where id=2;
commit;

• 1
• 2
• 3

根据update的更新原则:会生成新的一行,并在原来要修改的列的删除时间列上添加本事务ID,得到表如下:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	5
3	fei	1	undefined
4	tian	3	undefined
2	Long	5	undefined

继续执行事务2的(2),根据select 语句的检索条件,得到下表:

id	name	创建时间(事务ID)	删除时间(事务ID)
1	yang	1	4
2	long	1	5
3	fei	1	undefined

还是和事务2中(1)select 得到相同的结果.

 

Redis哨兵模式

简介

Redis-Sentinel是官方推荐的高可用解决方案，当redis在做master-slave的高可用方案时，假如master宕机了，redis本身（以及其很多客户端）都没有实现自动进行主备切换，而redis-sentinel本身也是独立运行的进程，可以部署在其他与redis集群可通讯的机器中监控redis集群。

功能

1、不时地监控redis是否按照预期良好地运行;
2、如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
3、能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
4、哨兵为客户端提供服务发现，客户端链接哨兵，哨兵提供当前master的地址然后提供服务，如果出现切换，也就是master挂了，哨兵会提供客户端一个新地址。

 

spring传播行为

PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

java线程通信的三种方式

1、传统的线程通信。

    在synchronized修饰的同步方法或者修饰的同步代码块中使用Object类提供的wait(),notify()和notifyAll()3个方法进行线程通信。

    关于这3个方法的解释：

 

1.     wait():导致当前线程等待，直到其他线程调用该同步监视器的notify()方法或notifyAll()方法来唤醒该线程。
2.     notify():唤醒在此同步监视器上等待的单个线程。
3.     notifyAll():唤醒在此同步监视器上等待的所有线程。

 

2、使用Condition控制线程通信。

    当程序使用Lock对象来保证同步，系统不存在隐式的同步监视器，只能用Condition类来控制线程通信。

 

1.      await():类似于隐式同步监视器上的wait()方法，导致当前线程等待，直到其他线程调用该Condition的signal()方法或signalAll()方法来唤醒该线程。
2.     signal():唤醒在此Lock对象上等待的单个线程。如果所有的线程都在该Lock对象上等待，则会选择唤醒其中一个线程。选择是任意性的。
3.     signalAll():唤醒在此Lock对象上等待的所有线程，只有当前线程放弃对该Lock对象的锁定后，才可以执行被唤醒的线程。

 

3、使用阻塞队列（BlockingQueue）控制线程通信（也实现了生产者消费者模式）

 

    BlockingQueue提供如下两个支持阻塞的方法：

1.     put(E e):尝试把E元素放入BlockingQueue中，如果该队列的元素已满，则阻塞该线程。
2.     take():尝试从BlockingQueue的头部取出元素，如果该队列的元素已空，则阻塞该线程。

top k 问题（寻找出最大的10000个数）

全部排序

然后在排序后的集合中进行查找，最快的排序算法的时间复杂度一般为O（nlogn），如快速排序。但是在32位的机器上，每个float类型占4个字节，1亿个浮点数就要占用400MB的存储空间，对于一些可用内存小于400M的计算机而言，很显然是不能一次将全部数据读入内存进行排序的。其实即使内存能够满足要求（我机器内存都是8GB），该方法也并不高效，因为题目的目的是寻找出最大的10000个数即可，而排序却是将所有的元素都排序了，做了很多的无用功。

 

 第二种方法为局部淘汰法，

该方法与排序方法类似，用一个容器保存前10000个数，然后将剩余的所有数字——与容器内的最小数字相比，如果所有后续的元素都比容器内的10000个数还小，那么容器内这个10000个数就是最大10000个数。如果某一后续元素比容器内最小数字大，则删掉容器内最小元素，并将该元素插入容器，最后遍历完这1亿个数，得到的结果容器中保存的数即为最终结果了。此时的时间复杂度为O（n+m^2），其中m为容器的大小，即10000。

 

第三种方法是分治法

将1亿个数据分成100份，每份100万个数据，找到每份数据中最大的10000个，最后在剩下的100*10000个数据里面找出最大的10000个。如果100万数据选择足够理想，那么可以过滤掉1亿数据里面99%的数据。100万个数据里面查找最大的10000个数据的方法如下：用快速排序的方法，将数据分为2堆，如果大的那堆个数N大于10000个，继续对大堆快速排序一次分成2堆，如果大堆个数N小于10000个，就在小的那堆里面快速排序一次，找第10000-n大的数字；递归以上过程，就可以找到第1w大的数。参考上面的找出第1w大数字，就可以类似的方法找到前10000大数字了。此种方法需要每次的内存空间为10^6*4=4MB，一共需要101次这样的比较。

 

第四种方法是Hash法。

如果这1亿个书里面有很多重复的数，先通过Hash法，把这1亿个数字去重复，这样如果重复率很高的话，会减少很大的内存用量，从而缩小运算空间，然后通过分治法或最小堆法查找最大的10000个数。

 

第五种方法采用最小堆。

首先读入前10000个数来创建大小为10000的最小堆，建堆的时间复杂度为O（mlogm）（m为数组的大小即为10000），然后遍历后续的数字，并于堆顶（最小）数字进行比较。如果比最小的数小，则继续读取后续数字；如果比堆顶数字大，则替换堆顶元素并重新调整堆为最小堆。整个过程直至1亿个数全部遍历完为止。然后按照中序遍历的方式输出当前堆中的所有10000个数字。该算法的时间复杂度为O（nmlogm），空间复杂度是10000（常数）。

 

把一个数组中的空格移动到最后

算法解释

此算法的精髓在于：在循环遍历中将0元素全部集中起来，整体向后移位，但是由于连续的0元素都是相等的，因此就算往前移位，也只需要将最前面的0元素和连续0元素的结束位置的后一位元素进行调换，相当于整个0元素块都向后移动了一位。
由于数组中可能有多个0，因此，第一次循环的时候，就将第一个0元素找出，并且记录当前0元素的游标(此时0元素开始的游标和结束的游标相等)，第二次循环的时候，直接从0元素结束的游标的后一位开始循环遍历，如果循环遍历过程中，遇到了0元素，则将0元素的结束游标+1；如果没有遇到0元素，则将0元素开始位置和当前位置的数进行置换，并且将0元素的开始游标和结束游标都+1。

符号引用与直接引用

符号引用 ：符号引用以一组符号来描述所引用的目标。符号引用可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可，符号引用和虚拟机的布局无关。个人理解为：在编译的时候一个每个java类都会被编译成一个class文件，但在编译的时候虚拟机并不知道所引用类的地址，多以就用符号引用来代替，而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。即直接引用。

最长回文子串

一、O(n^3)时间复杂度方法——暴力求解

1.思想：

    1）从最长的子串开始，遍历所有该原字符串的子串；

    2）每找出一个字符串，就判断该字符串是否为回文；

    3）子串为回文时，则找到了最长的回文子串，因此结束；反之，则继续遍历。

2.时间复杂度解释：

    遍历字符串子串：嵌套一个循环、O(n^2)；   

    判断是否为回文：再次嵌套一个循环、O(n^3)。

二、O(n^2)时间复杂度方法——从中心向外扩散

1.思想：

     1）将子串分为单核和双核的情况，单核即指子串长度为奇数，双核则为偶数；

    2）遍历每个除最后一个位置的字符index(字符位置)，单核：初始low = 初始high = index，low和high均不超过原字符串的下限和上限；判断low和high处的字符是否相等，相等则low++、high++（双核：初始high = 初始low+1 = index + 1）；

    3）每次low与high处的字符相等时，都将当前最长的回文子串长度与high-low+1比较。后者大时，将最长的回文子串改为low与high之间的；

    4）重复执行2）、3），直至high-low+1 等于原字符串长度或者遍历到最后一个字符，取当前截取到的回文子串，该子串即为最长的回文子串。

 

2.时间复杂度解释：

   遍历字符：一层循环、O(n-1)；

   找以当前字符为中心的最长回文子串：嵌套两个独立循环、O(2n*(n-1)) = O(n^2)。

三、O(n)时间复杂度方法——Manacher算法

1.思想：

    1）将原字符串S的每个字符间都插入一个永远不会在S中出现的字符（本例中用“#”表示），在S的首尾也插入该字符，使得到的新字符串S_new长度为2*S.length()+1，保证Len的长度为奇数(下例中空格不表示字符，仅美观作用)；

        例：S：       a  a  b  a  b  b  a

        S_new:        #  a  #  a  #  b  #  a  #  b  #  b  #  a  #

    2）根据S_new求出以每个字符为中心的最长回文子串的最右端字符距离该字符的距离，存入Len数组中，即S_new[i]—S_new[r]为S_new[i]的最长回文子串的右段（S_new[2i-r]—S_new[r]为以S_new[i]为中心的最长回文子串），Len[i] = r - i + 1;

        S_new:        #  a  #  a  #  b  #  a  #  b  #  b  #  a  #

        Len:            1  2  3  2  1   4  1  4  1  2  5   2  1  2  1

        Len数组性质：Len[i] - 1即为以Len[i]为中心的最长回文子串在S中的长度。在S_new中，以S_new[i]为中心的最长回文子串长度为2Len[i] - 1，由于在S_new中是在每个字符两侧都有新字符“#”，观察可知“#”的数量一定是比原字符多1的，即有Len[i]个，因此真实的回文子串长度为Len[i] - 1，最长回文子串长度为Math.max(Len) - 1。

    3）Len数组求解（线性复杂度（O(n)））：

       a.遍历S_new数组，i为当前遍历到的位置，即求解以S_new[i]为中心的最长回文子串的Len[i];

       b.设置两个参数：sub_midd = Len.indexOf(Math.max(Len)表示在i之前所得到的Len数组中的最大值所在位置、sub_side = sub_midd + Len[sub_midd] - 1表示以sub_midd为中心的最长回文子串的最右端在S_new中的位置。起始sub_midd和sub_side设为0，从S_new中的第一个字母开始计算，每次计算后都需要更新sub_midd和sub_side；

      c.当i < sub_side时，取i关于sub_midd的对称点j（j = 2sub_midd - i，由于i <= sub_side，因此2sub_midd - sub_side <= j <= sub_midd);当Len[j] < sub_side - i时，即以S_new[j]为中心的最长回文子串是在以S_new[sub_midd]为中心的最长回文子串的内部，再由于i、j关于sub_midd对称，可知Len[i] = Len[j];

    当Len[j] >= sub.side - i时说明以S_new[i]为中心的回文串可能延伸到sub_side之外，而大于sub_side的部分还没有进行匹配，所以要从sub_side+1位置开始进行匹配，直到匹配失败以后，从而更新sub_side和对应的sub_midd以及Len[i]；

 

        d.当i > sub_side时，则说明以S_new[i]为中心的最长回文子串还没开始匹配寻找，因此需要一个一个进行匹配寻找，结束后更新sub_side和对应的sub_midd以及Len[i]。

 

2.时间复杂度解释：

        算法只有遇到还没匹配的位置时才进行匹配，已经匹配过的位置不再进行匹配，因此大大的减少了重复匹配的步骤，对于S_new中的每个字符只进行一次匹配。所以该算法的时间复杂度为O(2n+1)—>O(n)（n为原字符串的长度），所以其时间复杂度依旧是线性的。

 

mysql死锁的原因以及解决方法

死锁的第一种情况

一个用户A 访问表A(锁住了表A),然后又访问表B；另一个用户B 访问表B(锁住了表B)，然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。

解决方法：

这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进 行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

死锁的第二种情况

用户A查询一条纪录，然后修改该条纪录；这时用户B修改该条纪录，这时用户A的事务里锁的性质由查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A 有共享锁存在所以必须等A释放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。这种死锁比较隐蔽，但在稍大点的项 目中经常发生。如在某项目中，页面上的按钮点击后，没有使按钮立刻失效，使得用户会多次快速点击同一按钮，这样同一段代码对数据库同一条记录进行多次操 作，很容易就出现这种死锁的情况。（b需要等待a释放共享锁以后才能加排他锁，而a需要拿到排他锁才能释放共享锁，故而形成死锁。看你就没仔细阅读作者的文章。）

解决方法：

1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。
2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是 通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数 据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据 库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造 成脏数据被更新到数据库中。
3、使用悲观锁进行控制。悲观锁大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统， 当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。所以，采用悲观锁进行控制时一定要考虑清楚。

死锁的第三种情况

如果在事务中执行了一条不满足条件的update语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，就很容易产生死锁和阻塞。类似的情 况还有当表中的数据量非常庞大而索引建的过少或不合适的时候，使得经常发生全表扫描，最终应用系统会越来越慢，最终发生阻塞或死锁。

解决方法：

SQL语句中不要使用太复杂的关联多表的查询；使用“执行计划”对SQL语句进行分析，对于有全表扫描的SQL语句，建立相应的索引进行优化。

线程池拒绝策略

ThreadPoolExcetor 的最后一个参数指定了拒绝策略，JDK提供了四种拒绝策略：
AbortPolicy 策略、CallerRunsPolicy策略、 DiscardOledestPolicy策略、DiscardPolicy策略。

AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作。

CallerRunsPolicy 策略：只要线程池未关闭，该策略直接在调用者线程中，运行当前的被丢弃的任务。

DiscardOleddestPolicy策略： 该策略将丢弃最老的一个请求，也就是即将被执行的任务，并尝试再次提交当前任务。

DiscardPolicy策略：该策略默默的丢弃无法处理的任务，不予任何处理。

mysql索引失效的几种情况（全）

1.WHERE字句的查询条件里有不等于号（WHERE column!=…），MYSQL将无法使用索引

2.类似地，如果WHERE字句的查询条件里使用了函数（如：WHERE DAY(column)=…），MYSQL将无法使用索引

3.在JOIN操作中（需要从多个数据表提取数据时），MYSQL只有在主键和外键的数据类型相同时才能使用索引，否则即使建立了索引也不会使用

4.如果WHERE子句的查询条件里使用了比较操作符LIKE和REGEXP，MYSQL只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。比如说，如果查询条件是LIKE 'abc%',MYSQL将使用索引；如果条件是LIKE '%abc'，MYSQL将不使用索引。

5.在ORDER BY操作中，MYSQL只有在排序条件不是一个查询条件表达式的情况下才使用索引。尽管如此，在涉及多个数据表的查询里，即使有索引可用，那些索引在加快ORDER BY操作方面也没什么作用。

6.如果某个数据列里包含着许多重复的值，就算为它建立了索引也不会有很好的效果。比如说，如果某个数据列里包含了净是些诸如“0/1”或“Y/N”等值，就没有必要为它创建一个索引。

7.索引有用的情况下就太多了。基本只要建立了索引，除了上面提到的索引不会使用的情况下之外，其他情况只要是使用在WHERE条件里，ORDER BY 字段，联表字段，一般都是有效的。 建立索引要的就是有效果。 不然还用它干吗？ 如果不能确定在某个字段上建立的索引是否有效果，只要实际进行测试下比较下执行时间就知道。

8.如果条件中有or(并且其中有or的条件是不带索引的)，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)。注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引

9.如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,否则不使用索引

10.如果mysql估计使用全表扫描要比使用索引快,则不使用索引

 

链表的倒数第k个节点

　　为了能够只遍历一次就能找到倒数第k个节点，可以定义两个指针：

　　（1）第一个指针从链表的头指针开始遍历向前走k-1，第二个指针保持不动；

　　（2）从第k步开始，第二个指针也开始从链表的头指针开始遍历；

　　（3）由于两个指针的距离保持在k-1，当第一个（走在前面的）指针到达链表的尾结点时，第二个指针（走在后面的）指针正好是倒数第k个结点。

 

Java 8中基本数据类型占用字节数

8中基本数据类型为：
4种整形：byte(取值-128~127),short（取值-32768~32767），int，long
2种浮点类型：float，double（3.14F位浮点型，没有F默认为double）
1种Unicode编码的字符单元的字符型：char
1中Boolean类型：boolean
8中类型所占字节和位数如下：

类型	占用字节	占用位数
byte	1	8
short	2	16
int	4	32
long	8	64
float	4	32
double	8	64
char	2	16
boolean	1	8

TCP/IP协议族四层模型简述

从上层到底层为：应用层，传输层，网络层， 数据链路层。

 

TCP和UDP协议的比较

1： 面向报文

面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。

2： 面向字节流

面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

TCP和UDP最主要的区别是TCP是可靠传输的，UDP是不可靠传输的。所以如果我们的发送消息之类的场景，因为你要确保用户的消息不会丢失，需要使用TCP协议。如果你是在进行视频聊天或者看直播，那你可以使用UDP协议，因为即使几个画面丢失了，对用户来说影响也不是很大。哪些应用层协议使用TCP，哪些使用UDP的话，你自己去查一下，懒得打字了。

 

TCP滑动窗口协议

滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。

（1）发送方不必发送一个全窗口大小的数据。 
（2）来自接收方的一个报文段确认数据并把窗口向右边滑动，这是因为窗口的大小是相对于确认序号的。 
（3）窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。 
（4）接收方在发送一个ACK前不必等待窗口被填满。

TCP的滑动窗口主要有两个作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。

可靠：对发送的数据进行确认

流控制：窗口大小随链路变化。

一、tcp窗口机制

tcp中窗口大小是指tcp协议一次传输多少个数据。因为TCP是一个面向连接的可靠的传输协议，既然是可靠的就需要对传输的数据进行确认。TCP的窗口机制有两种，一种是固定窗口大小，另一种是滑动窗口。数据在传输时,TCP会对所有数据进行编号，发送方在发送过程中始终保持着一个窗口，只有落在发送窗口内的数据帧才允许被发送；同时接受方也始终保持着一个接收窗口，只有落在窗口内的数据才会被接收。这样通过改变发送窗口和接收窗口的大小就可以实现流量控制。

二、tcp窗口大小

tcp的窗口滑动技术通过动态改变窗口的大小来调节两台主机之间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口，一个用于接收数据，一个用于发送数据。接收方设备要求窗口大小为0时，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。

TCP在传送数据时，第一次发数据发送方的窗口大小是由链路带宽决定的，但是接受方在接收到发送方的数据后，返回ack确认报文，同时也告诉了发送方自己的窗口大小，此时发送发第二次发送数据时，会改变自己的窗口大小和接受方一致。

当窗口过大时，会导致不必要的数据来拥塞我们的链路，但是窗口太小时，会造成很大的延时，比如为1时，发送方没发送一个数据，接受方就会返回一个ack报文，在发送方未接收到接受方的确认报文ack之前不会进行下一次发送。当链路变好了或者变差了这个窗口还会发生变话，并不是第一次协商好了以后就永远不变了。

三、窗口滑动协议

是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待接收确认报文前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。

慢启动:

定义：

慢启动是一种TCP拥塞控制机制，基本思想是TCP开始在一个网络中传输数据或发现数据丢失并开始重发时，首先慢慢的对网路实际容量进行试探，避免由于发送了过量的数据而导致阻塞。

过程：

慢启动为发送方的TCP增加了另一个窗口：拥塞窗口。TCP发送方在初始阶段不是线性地增加其发送速率，而是以指数的速度增加，即每过一个RTT将拥塞窗口值翻倍（初始值为1个报文段）。TCP发送方继续以指数速度增加其发送速率，直到发生一个丢包事件，此时拥塞窗口值将被降为一半。发送方取拥塞窗口与通告窗口的最小值为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。

快重传（Fast Retransmit）

• 要求接收方每收到一个失序的报文段后就立即发出重复确认而不是等待自己发送数据时才捎带确认

• 发送方只要一连收到三个重复确认就立即重传对方尚未收到的报文段，而不必等待设置的重传计时器到期

什么是https协议？https协议用到了哪种密钥？

https是在http上面套了一层ssl，用来实现安全连接。用到的密钥有对称密钥和非对称密钥。目前基本上大一点的网站，都会使用https

（一）对称加密（Symmetric Cryptography）*

对称密钥加密，又称私钥加密，即信息的发送方和接收方用一个密钥去加密和解密数据。它的最大优势是加/解密速度快，适合于对大数据量进行加密，对称加密的一大缺点是密钥的管理与分配，换句话说，如何把密钥发送到需要解密你的消息的人的手里是一个问题。在发送密钥的过程中，密钥有很大的风险会被黑客们拦截。现实中通常的做法是将对称加密的密钥进行非对称加密，然后传送给需要它的人。

对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率，是一个trade-off。

（二）非对称加密（Asymmetric Cryptography）*

非对称密钥加密系统，又称公钥密钥加密。非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人--银行才能对你的消息解密。与对称加密不同的是，银行不需要将私钥通过网络发送出去，因此安全性大大提高。 目前最常用的非对称加密算法是RSA算法。公钥机制灵活，但加密和解密速度却比对称密钥加密慢得多。

什么是左连接，什么是右连接，什么是全连接，什么是内连接？

1.内连接

1.1.等值连接：在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结果中列出被连接表中的所有列，包括其中的重复列。

1.2.不等值连接：在连接条件使用除等于运算符以外的其它比较运算符比较被连接的列的列值。这些运算符包括>、>=、<=、<、!>、!<和<>。

1.3.自然连接：在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选择列表指出查询结果集合中所包括的列，并删除连接表中的重复列。

2.外连接

2.1.左联接：是以左表为基准，将a.stuid = b.stuid的数据进行连接，然后将左表没有的对应项显示，右表的列为NULL

2.2.右连接：是以右表为基准，将a.stuid = b.stuid的数据进行连接，然以将右表没有的对应项显示，左表的列为NULL

2.3.全连接：完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。

3.交叉连接

交叉连接：交叉联接返回左表中的所有行，左表中的每一行与右表中的所有行组合。交叉联接也称作笛卡尔积。

SQL注入

防止SQL注入，在jdbc中一种有效的方法就是使用prepareStatement，prepareStatement其实就是使用了预编译的方式来防止SQL注入的。

缓存过期策略

1.FIFO（First In First out）：先见先出，淘汰最先近来的页面，新进来的页面最迟被淘汰，完全符合队列。

2.LRU（Least recently used）:最近最少使用，淘汰最近不使用的页面

3.LFU（Least frequently used）: 最近使用次数最少， 淘汰使用次数最少的页面

 

ConcurrentModifyException的产生原因及如何避免(即fail-fast）

如果不符合条件则将该对象从集合中移除。这种情况很容易产生ConcurrentModificationExceptionException，这个异常会导致程序停止继续运行，所以遇到这个异常必须要处理来保证程序正确运行。

 

二.在单线程环境下的解决办法

在Itr类中也给出了一个remove()方法：

在这个方法中，删除元素实际上调用的就是list.remove()方法，但是它多了一个操作：

expectedModCount = modCount;

public class Test {
    public static void main(String[] args)  {
        ArrayList list = new ArrayList();
        list.add(2);
        Iterator iterator = list.iterator();
        while(iterator.hasNext()){
            Integer integer = iterator.next();
            if(integer==2)
                iterator.remove();   //注意这个地方
        }
    }
}

　多线程还是会有问题

　　有可能有朋友说ArrayList是非线程安全的容器，换成Vector就没问题了，实际上换成Vector还是会出现这种错误。

　　原因在于，虽然Vector的方法采用了synchronized进行了同步，但是实际上通过Iterator访问的情况下，每个线程里面返回的是不同的iterator，也即是说expectedModCount是每个线程私有。假若此时有2个线程，线程1在进行遍历，线程2在进行修改，那么很有可能导致线程2修改后导致Vector中的modCount自增了，线程2的expectedModCount也自增了，但是线程1的expectedModCount没有自增，此时线程1遍历时就会出现expectedModCount不等于modCount的情况了。

　

因此一般有2种解决办法：

　　1）在使用iterator迭代的时候使用synchronized或者Lock进行同步；

　　2）使用并发容器CopyOnWriteArrayList代替ArrayList和Vector。

TIME_WAIT多了有什么问题？

   为什么一定要有TIME_WAIT的状态？能否直接进入CLOSEED？不能，TCP是建立在不可靠网络上的可靠协议，主动方发送的ACK包可能延迟，从而触发被动方的FIN包重传，这一来一去，就是2MSL的时间。因此，必须要有这个状态，以保证TCP的可靠性。否则，如果当重传的FIN包到达后，可能导致两个问题：

     1. 旧连接已经不在，只能返回RST包，被动关闭的一方无法关闭TCP连接

     2. 新连接已经建立，FIN包可能对新连接有干扰。

     所以，TIME_WAIT不能没有，但不能太多，该考虑限制它的数量。

spring加载配置文件三办法

1、把applicationContext.xml直接放在WEB-INF/classes下，spring会采用默认的加载方式

2、采用在web.xml中配置ContextLoaderListenera或ContextLoaderServlet指定加载路径方式。它们两个有着同样的功能,都实现在了org.springframework.web.context.ContextLoader类,都要定义contextConfigLocation参数。区别在于listener不能在Servlet 2.2兼容的容器中使用。

代码
 
    contextConfigLocation 
     
      /WEB-INF/daoContext.xml,  
     /WEB-INF/config/appContext1.xml,  
    /WEB-INF/config/appContext2.xml  
 
 
 
 
    org.springframework.web.context.ContextLoaderListener 
 
 

3 通过ClassPathXmlApplicationContext或XmlWebApplicationContext代码动态加载!

 

 

浏览器中网址访问过程(详细）

（1）浏览器本身是一个客户端，当你输入URL的时候，首先浏览器会去请求DNS服务器，通过DNS获取相应的域名对应的IP
（2）然后通过IP地址找到IP对应的服务器后，要求建立TCP连接
（3）浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包
（4）在服务器收到请求之后，服务器调用自身服务，返回HTTP Response（响应）包
（5）客户端收到来自服务器的响应后开始渲染这个Response包里的主体（body），等收到全部的内容随后断开与该服务器之间的TCP连接。 

1. DNS解析

具体的查找过程和策略可以分为下面这几步：
（1）在浏览器中输入www.google.cn域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
（2）如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
（3）如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
（4）如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
（5）如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(google.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找google.com域服务器，重复上面的动作，进行查询，直至找到www.google.com主机。
（6）如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

2. Socket建立连接

当我们输入这样一个请求时，首先要建立一个socket连接，因为socket是通过ip和端口建立的，所以之前还有一个DNS解析过程，把www.google.com变成ip，如果url里不包含端口号，则会使用该协议的默认端口号。

3. 发送HTTP请求

连接成功建立后，开始向web服务器发送请求，当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成： 
（1）请求方法URI协议/版本 
（2）请求头(Request Header) 
（3）请求正文 

3.1 请求方法URI协议/版本

请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1``
以上代码中“GET”代表请求方法，/sample.jsp表示URI，HTTP/1.1“`代表协议和协议的版本。
根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。
URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。

3.2 请求头(Request Header)

请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.

3.3 请求正文

请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：

username=jinqiao&password=1234

在以上的例子的HTTP请求中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

3.4 HTTP请求方法：GET方法与POST方法

3.4.1 GET方法

GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大

3.4.2 POST方法

POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。

3.5 各种HTTP请求的含义

GET
通过请求URI得到资源
POST
用于添加新的内容
PUT
用于修改某个内容
DELETE
删除某个内容
CONNECT
用于代理进行传输，如使用SSL
OPTIONS
询问可以执行哪些方法
PATCH
部分文档更改
PROPFIND
查看属性
PROPPATCH
设置属性
MKCOL
创建集合（文件夹）
COPY
拷贝
MOVE
移动
LOCK
加锁
UNLOCK
解锁
TRACE
用于远程诊断服务器
HEAD
类似于GET, 但是不返回body信息，用于检查对象是否存在，以及得到对象的元数据

4.1 HTTP响应报文头

HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：
（1）协议状态版本代码描述
（2）响应头(Response Header)
（3）响应正文
下面是一个HTTP响应的例子：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112