1. 什么是线程？进程？N和线程和进程有什么区别？
每个进程是一个应用程序，都有独立的内存空间 同一个进程中的线程共享其进程中的内存和资源（共享的内存是堆内存和方法区内存，栈内存不共享，每个线程有自己的。）
进程是指一个内存中运行的应用程序，每个进程都有自己独立的一块内存空间，一个进程中可以启动多个线程。
比如在Windows系统中，一个运行的exe就是一个进程。
多线程不是为了提高执行速度，而是提高应用程序的使用率,即CPU使用率。
线程和线程共享“堆内存和方法区内存”，栈内存是独立的，一个线程一个栈
- 什么时候用到多线程？
A： 吞吐量：你做WEB，容器帮你做了多线程，但是他只能帮你做请求层面的。简单的说，可能就是一个请求一个线程。或多个请求一个线程。如果是单线程，那同时只能处理一个用户的请求。
B： 当一个程序 执行很长一段时间，但是程序执行的时候，操作者不想等待这段时间，而是想干些别的事情。此时需要使用多线程。
C: 在编写程序时，遇到了阻塞过程而不想使整个程序停止响应时，应使用多线程；一个程序的合理线程数量取决于对实际阻塞的抽象程度。
D：举例：
假设有个请求，这个请求服务端的处理需要执行3个很缓慢的IO操作（比如数据库查询或文件查询），那么正常的顺序可能是（括号里面代表执行时间）：
a、读取文件1 （10ms）
b、处理1的数据（1ms）
c、读取文件2 （10ms）
d、处理2的数据（1ms）
e、读取文件3 （10ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）
单线程总共就需要34ms。
那如果你在这个请求内，把ab、cd、ef分别分给3个线程去做，就只需要12ms了。
假设还是上面那个相同的问题：但是每个步骤的执行时间不一样了。
a、读取文件1 （1ms）
b、处理1的数据（1ms）
c、读取文件2 （1ms）
d、处理2的数据（1ms）
e、读取文件3 （28ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）
单线程总共就需要34ms。
如果还是按上面的划分方案（上面方案和木桶原理一样，耗时取决于最慢的那个线程的执行速度），在这个例子中是第三个线程，执行29ms。那么最后这个请求耗时是30ms。比起不用单线程，就节省了4ms。但是有可能线程调度切换也要花费个1、2ms。因此，这个方案显得优势就不明显了，还带来程序复杂度提升。不太值得。
那么现在优化的点，就不是第一个例子那样的任务分割多线程完成。而是优化文件3的读取速度。
可能是采用缓存和减少一些重复读取。
首先，假设有一种情况，所有用户都请求这个请求，那其实相当于所有用户都需要读取文件3。那你想想，100个人进行了这个请求，相当于你花在读取这个文件上的时间就是28×100=2800ms了。那么，如果你把文件缓存起来，那只要第一个用户的请求读取了，第二个用户不需要读取了，从内存取是很快速的，可能1ms都不到。
多线程的缺点？
(1)等候使用共享资源时造成程序的运行速度变慢。
这些共享资源主要是独占性的资源 ,如打印机等。(2)对线程进行管理要求额外的CPU开销。
线程的使用会给系统带来上下文切换的额外负担。当这种负担超过一定程度时,多线程的特点主要表现在其缺点上,比如用独立的线程来更新数组内每个元素。(3)线程的死锁。
即较长时间的等待或资源竞争以及死锁等多线程症状。(4)线程不安全
死锁
脏数据
对公有变量的同时读或写。当多个线程需要对公有变量进行写操作时,后一个线程往往会修改掉前一个线程存放的数据,从而使前一个线程的参数被修改;
另外当公用变量的读写操作是非原子性时,在不同的机器上,中断时间的不确定性,会导致数据在一个线程内的操作产生错误,从而产生莫名其妙的错误,而这种错误是程序员无法预知的。
但是上面买下了了一个坑，就是如何把文件缓存起来？
- 什么是线程安全？
并行与并发：
并行：多个cpu实例或者多台机器同时执行一段处理逻辑，是真正的同时。
并发：通过cpu调度算法，让用户看上去同时执行，实际上从cpu操作层面不是真正的同时。并发往往在场景中有公用的资源，那么针对这个公用的资源往往产生瓶颈，我们会用TPS或者QPS来反应这个系统的处理能力。
经常用来描绘一段代码。指在并发的情况之下，该代码经过多线程使用，线程的调度顺序不影响任何结果。这个时候使用多线程，我们只需要关注系统的内存，cpu是不是够用即可。反过来，线程不安全就意味着线程的调度顺序会影响最终结果，如不加事务的转账代码：
一、线程安全在三个方面体现
1.原子性：
提供互斥访问，同一时刻只能有一个线程对数据进行操作，（atomic,synchronized）；2.可见性：
一个线程对主内存的修改可以及时地被其他线程看到，（synchronized,volatile）；3.有序性：
一个线程观察其他线程中的指令执行顺序，由于指令重排序，该观察结果一般杂乱无序，（happens-before原则）。
synchronized 之 《原子性》
JDK提供锁分两种：一种是synchronized，依赖JVM实现锁，因此在这个关键字作用对象的作用范围内是同一时刻只能有一个线程进行操作；另一种是LOCK，是JDK提供的代码层面的锁，依赖CPU指令，代表性的是ReentrantLock。
synchronized修饰的对象有四种：
（1）修饰代码块，作用于调用的对象；
（2）修饰方法，作用于调用的对象；
（3）修饰静态方法，作用于所有对象；
（4）修饰类，作用于所有对象。
//synchronized 是对对象加锁
//采用 synchronized 同步最好只同步有线程安全的代码
//可以优先考虑使用 synchronized 同步块
//因为同步的代码越多，执行的时间就会越长，其他线程等待的时间就会越长
//影响效率
volatile 之 《可见性》
JVM提供了synchronized和volatile。这里我们看volatile
（1）volatile的可见性是通过内存屏障和禁止重排序实现的
A: volatile会在写操作时，会在写操作后加一条store屏障指令，
将本地内存中的共享变量值刷新到主内存：
B: volatile在进行读操作时，会在读操作前加一条load指令，从内存中读取共享变量：
（2）但是volatile不是原子性的，进行++操作不是安全的
为什么++的时候不安全？
原因是执行conut++时分成了三步，
第一步是取出当前内存count值，这时count值时最新的，
接下来执行了两步操作，分别是+1和重新写回主存。
假设有两个线程同时在执行count++，两个内存都执行了第一步，
比如当前count值为5，它们都读到了，然后两个线程分别执行了+1，
并写回主存，这样就丢掉了一次加一的操作。
（3）volatile适用的场景
既然volatile不适用于计数，那么volatile适用于哪些场景呢：
1. 对变量的写操作不依赖于当前值
2. 该变量没有包含在具有其他变量不变的式子中
因此，volatile适用于状态标记量：
volatile boolean inited =false ;
//线程1
context =loadContext() ;
inined =true ;
//线程2
While(!inined ){
sleep();
}
doSomethingWithConfig(context );
线程1负责初始化，线程2不断查询inited值，当线程1初始化完成后，线程2就可以检测到inited为true了。
通过volatile、synchronized、lock保证有序性。
有序性是指，在JMM中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。
另外，JMM具有先天的有序性，即不需要通过任何手段就可以得到保证的有序性。这称为happens-before原则。
如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性。虚拟机可以随意地对它们进行重排序。
happens-before原则：
1.程序次序规则：在一个单独的线程中，按照程序代码书写的顺序执行。
2.锁定规则：一个unlock操作happen—before后面对同一个锁的lock操作。
3.volatile变量规则：对一个volatile变量的写操作happen—before后面对该变量的读操作。
4.线程启动规则：Thread对象的start()方法happen—before此线程的每一个动作。
5.线程终止规则：线程的所有操作都happen—before对此线程的终止检测，可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
6.线程中断规则：对线程interrupt()方法的调用happen—before发生于被中断线程的代码检测到中断时事件的发生。
7.对象终结规则：一个对象的初始化完成（构造函数执行结束）happen—before它的finalize()方法的开始。
8.传递性：如果操作A happen—before操作B，操作B happen—before操作C，那么可以得出A happen—before操作C。
- 怎么样保证线程安全？
同步：Java中的同步指的是通过人为的控制和调度，保证共享资源的多线程访问成为线程安全，来保证结果的准确。如上面的代码简单加入@synchronized关键字。在保证结果准确的同时，提高性能，才是优秀的程序。线程安全的优先级高于性能。
这个问题和线程安全体现的三个方面答案是一样的。
线程优先级
线 程 优 先 级 主 要 分 三 种 ： MAX_PRIORITY( 最 高 级 );MIN_PRIORITY （ 最 低 级
）NORM_PRIORITY(标准)默认//设置线程的优先级，线程启动后不能再次设置优先级 //必须在启动前设置优先级 //设置最高优先级
t1.setPriority(Thread.MAX_PRIORITY);
sleep
sleep 设置休眠的时间,单位毫秒，当一个线程遇到 sleep 的时候，就会睡眠，进入到阻塞状态,放弃 CPU，腾出 cpu时间片，给其他线程用，所以在开发中通常我们会这样做，使其他的线程能够取得 CPU 时间片，当睡眠时间到达了，线程会进入可运行状态，得到 CPU 时间片继续执行，如果线程在睡眠状态被中断了，将会抛出 IterruptedException
停止一个线程
如果我们的线程正在睡眠，可以采用 interrupt 进行中断 通常定义一个标记，来判断标记的状态停止线程的执行
yield
它与 sleep()类似，只是不能由用户指定暂停多长时间，并且 yield()方法只能让同优先级的线程有执行的机会,采用 yieid 可以将CPU 的使用权让给同一个优先级的线程
join
当前线程可以调用另一个线程的 join 方法，调用后当前线程会被阻塞不再执行，直到被调用的线程执行完毕，当前线程才会执行
守护线程
从线程分类上可以分为：用户线程（以上讲的都是用户线程），另一个是守护线程。守护线程是这样的，所有的用户线程结束生命周期，守护线程才会结束生命周期，只要有一个用户线程存在，那么守护线程就不会结束，例如
java 中著名的垃圾回收器就是一个守护线程，只有应用程序中所有的线程结束，它才会结束。其它所有的用户线程结束,则守护线程退出! 守护线程一般都是无限执行的.
**上面说了这么多，往往面试官会问一个问题，如何解决并发的问题？**
首先补充一些并发可能带来的问题？
脏数据
脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这
个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据(Dirty Data)，依据脏数据所做的操作可能是不正确的。
不可重复读
不可重复读是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读
回来问题，如何处理并发和同步？
今天讲的如何处理并发和同同步问题主要是通过锁机制。
我们需要明白，锁机制有两个层面。
一种是代码层次上的，如java中的同步锁，典型的就是同步关键字synchronized，这里我不在做过多的讲解，
另外一种是数据库层次上的，比较典型的就是悲观锁和乐观锁。这里我们重点讲解的就是悲观锁（传统的物理锁）和乐观锁。
悲观锁(Pessimistic Locking):
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自 外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能
真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系 统不会修改数据）。
乐观锁(Optimistic Locking):
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依 靠数据库的锁机制实现，以保证操作最大程度的独占性。
但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。 如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进 行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作 员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几 百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本 Version
）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version”
字段来 实现。 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提
交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据 版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。 操作员 A
此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。2 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（ version=1 ），并 从其帐户余额中扣除 $20 （
$100-$20 ）。3 操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣 除后余额（ balance=$50 ），提交
至数据库更新，此时由于提交数据版本大 于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。4 操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数 据（ balance=$80
），但此时比对数据库记录版本时发现，操作员 B 提交的 数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记
录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。 这样，就避免了操作员 B 用基于version=1
的旧数据修改的结果覆盖操作 员 A 的操作结果的可能。从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系 统整体性能表现。 需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局 限性，
如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户 余额更新操作不受我们系统的控制，因此可能
会造成脏数据被更新到数据库中。
在 系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如 将乐观锁策略在数据库存储过程中实
现，对外只开放基于此存储过程的数据更新途 径，而不是将数据库表直接对外公开）
常见的提高高并发下访问的效率的手段
首先要了解高并发的的瓶颈在哪里？
1、可能是服务器网络带宽不够
2.可能web线程连接数不够 3.可能数据库连接查询上不去。
根据不同的情况，解决思路也不同。
像第一种情况可以增加网络带宽，DNS域名解析分发多台服务器。负载均衡，前置代理服务器nginx、apache等等
数据库查询优化，读写分离，分表等等
最后复制一些在高并发下面需要常常需要处理的内容:
尽量使用缓存，包括用户缓存，信息缓存等，多花点内存来做缓存，可以大量减少与数据库的交互，提高性能。
用jprofiler等工具找出性能瓶颈，减少额外的开销。
优化数据库查询语句，减少直接使用hibernate等工具的直接生成语句（仅耗时较长的查询做优化）。
优化数据库结构，多做索引，提高查询效率。
统计的功能尽量做缓存，或按每天一统计或定时统计相关报表，避免需要时进行统计的功能。
能使用静态页面的地方尽量使用，减少容器的解析（尽量将动态内容生成静态html来显示）。
解决以上问题后，使用服务器集群来解决单台的瓶颈问题。
什么时候用到LinkedeHashMap?为什么要用hashmap?