前言：
本人就我自己在面试中遇到的一些问题做了一个总结，在面试过程中有的问题答上来了，有些回答的感觉不尽人意，有些的遇到的问题问我的一脸懵逼。所以写一个文档出来，以激励自己还有不足的地方，遇到一次不会，下次就不要不懂了，要有点进步。
1．哪些情况可以终止当前线程的运行?
A、抛出一个例外时。
B、当该线程调用sleep()方法时。
C、当创建一个新线程时。
D、当一个优先级高的线程进入就绪状态时。
答案：AD
解释：A！pthread_clean_pop抛出一个例外，线程终止！也可以通过其他线程调用pthread_cancel（）函数来终止另一个线程， 当前选择选A。
D并不是终止，而是抢占，进程是资源分配的最基本单位，同一个进程创建的不同线程共享这些资源。所以这些线程能使用的资源是有限的。 当某一个线程优先级比较高时，它就会抢占其他线程的资源，导致其他线程没有资源可用，会造成阻塞，直到那个优先级高地线程使用完。 一般创建线程的时候都会有个属性绑定，在那里边就可以设置线程的响应速度。我这样讲，你明白了吗？所以D根本根本不能教终止， 只能叫挂起当前线程!
2．下面哪为构造函数的特性定义
A. 在类中声明构造函数时，名称须与类名相同
B. 具有重载特性，可以建立多个相同名称
C. 使用类建立新对象时，会自动执行构造函数，因此在构造函数内设定变量的初始值进行内存的分配
D. 以上都是
答案：D
3．java关于异常处理机制的叙述哪些正确
A. catch部分捕捉到异常情况时，才会执行finally部分
B. catch部分捕捉到异常情况时，才会执行finally部分
C. 不论程序是否发生异常及捕获到异常，都会执行finally部分
D. 以上都是
答案：B C
4. 下列关于接口的叙述中哪些是错误的
a. 接口中的数据必须设定初值（就是接口中的常量）
b. 接口中的方法都是抽象方法
c. 接口可以声明引用Area
d. 以上都正确
答案：AD
5. Java语言中，方法的重写（Overriding）和重载（Overloading）是多态性的不同表现。下边哪些说法是对的？（选择两项）
A． 重写是父类与子类之间多态性的一种表现。
B． 重写是一个类中多态性的一种表现。
C． 重载是一个类中多态性的一种表现。
D． 重载是父类与子类之间多态性的一种表现。
答案：A C
6．方法可以进行servlet的调试？
A、使用打印语句;在桌面计算机上运行服务器
B、使用Apache Log4J
C、使用IDE集成的调试器
D、直接查看HTML源码
E、返回错误页面给客户
答案：A B C D E
7．下面关于servlet的功用说法正确的有哪些？
A、读取客户程序发来的显式数据
B、读取客户程序发来的隐式数据
C、生成相应的结果
D、发送显式的数据给客户程序
E、发送隐式的数据给客户程序
答案：A B C D E
8．下面关于session的用法哪些是错误的？
A、HttpSession session = new HttpSession( );
B、String haha = session.getParameter(“haha” );
C、session.removeAttribute( “haha” );
D、session.set Attribute( “haha” );
答案：A B D
9．正则表达式(01|10|1001|0110)*与下哪个表达式一样
A、(0|1)*
B、(01|01)*
C、(01|10)*
D、(11|01)*
E、(01|1)*
答案：C
解释：因为1001，0110里面都包含01，故可省去
10．关于bean的说法不正确的有哪些？
A、具备一个零参数（空）的构造函数（不是必须的）
B、不应有公开的实例变量（字段）
C、所有的属性必须通过getXxx和setXxxg来访问
D、布尔型的属性使用isXxx，而非getXxx
答案：B D
11.下面关于MVC说法错误的有哪些？
A、必须使用复杂的框架
B、使用内建的RequestDispatcher能够很好地实现MVC
C、MVC影响整个系统的设计
D、我们可以用MVC来处理单个请求
答案：A C
12.下面那个Ruable接口的方法
A、run
B、start
C、yield
D、stop
答案：A
13.下面代码运行的结果是什么？
public class Test{ public int aMethod(){ static int i=0; i++; return i; } public static void main(String[] args) { Test test =new Test(); test.aMethod(); int j=test.aMethod(); System.out.println(j); } }
A、编译失败
B、编译成功和程序打出“0”
C、编译成功和程序打出“1”
D、编译成功和程序打出“2”
答案：A
14.下列正确的有（）
A、call by value 不会改变实际参数的数值
B、call by reference 能改变实际参数的参考地址
C、call by reference不能改变实际参数的参考地址
D、call by reference 能改变实际参数的内容
答案：ACD
15.执行如下程序代码：
a=0; c=0; do{ --c; a=a-1; }while(a>0);后，C的值是（）
A、0
B、1
C、-1
D、死循环
答案： 这道题只能根据选项来补全代码了，因为代码并不完整，变量a和c的类型没有声明。先来看a，如果a是有符号数，则循环只执行一次，再根据选项可知，c同样为有符号数，选C；如果a是无符号数，a=a-1，第一次循环过后，a变为可以表示的有效范围内的最大无符号数，继续执行循环直到减为0，c和a的初始值都为0，当循环结束时c被减了一圈，同样为0，可以选A。
1．Short s1=1;s1=s1+1;有什么错？short s1=1;s1+=1;有什么错？
答案：对于short s1 = 1; s1 = s1 + 1; 由于s1+1运算时会自动提升表达式的类型，所以结果是int型，再赋值给short类型s1时，编译器将报告需要强制转换类型的错误。对于short s1 = 1; s1 += 1;由于 += 是java语言规定的运算符，java编译器会对它进行特殊处理，因此可以正确编译。
2．Try{}里面有一个return语句，那么紧跟在这个try后的finally{}里的code会不会被执行，什么时候执行，在return前还是后？
根据java规范：在try-catch-finally中，如果try-finally或者catch-finally中都有return，则两个return语句都执行并且最终
返回到调用者那里的是finally中return的值；而如果finally中没有return，则理所当然的返回的是try或者catch中return的值，但是
finally中的代码是必须要执行的,而且是在return前执行,除非碰到exit()。
jsp和servlet有哪些共同点和不同点，之间的联系又是什么？
jSP是Servlet技术的扩展，本质上是Servlet的简易方式，更强调应用的外表表达。 JSP编译后是"类servlet"。Servlet和JSP最主要的不同点在于， Servlet的应用逻辑是在Java文件中，并且完全从表示层中的HTML里分离开来。 而JSP的情况是Java和HTML可以组合成一个扩展名为.jsp的文件。 JSP侧重于视图，Servlet主要用于控制逻辑。 JSP和Servlet和本质上都是java类。你编写的jsp文件，初看起来虽然绝对不像一个java类， 但当你把它部署到容器中后，如tomcat。tomcat将会把它翻译为Servlet，最后在把它编译为.class文件。 你可以在“[TOMCAT_HOME]\work\Catalina\localhost\应用程序名称”中看到。 1.既然jsp归根结底是servlet，那为啥发明个这玩意呢？ 最直接的原因是：在servlet写html会恶心死人的，呵呵。 2.为什么容器（tomcat）先把它翻译成Servlet（java），在编译成.class? 为何不一步到位？ 因为我们已经有java->.class这一部分了，利用jsp->Servlet（java）->.class 不是少开发了一部分
3．写个singleton出来
首先，单例模式是对象的创建模式之一，此外还包括工厂模式。单例模式的三个特点：
1，该类只有一个实例
2，该类自行创建该实例(在该类内部创建自身的实例对象)
3，向整个系统公开这个实例接口
Java中大概是这个样子
class Singleton {
//私有，静态的类自身实例
private static Singleton instance= new Singleton();
//私有的构造子(构造器,构造函数,构造方法)
private Singleton(){}
//公开，静态的工厂方法
public static SingletongetInstance() {
returninstance;
}
}
使用时
1 | Singleton obj = Singleton.getInstance(); |
这个单例类在自身被加载时instance会被实例化，即便加载器是静态的。因此，对于资源密集，配置开销较大的单体更合理的做法是将实例化(new)推迟到使用它的时候。即惰性加载(Lazy loading)，它常用于那些必须加载大量数据的单体。修改下
class LazySingleton {
//初始为null，暂不实例化
private static LazySingletoninstance = null;
//私有的构造子(构造器,构造函数,构造方法)
private LazySingleton(){}
//公开，静态的工厂方法，需要使用时才去创建该单体
public static LazySingleton getInstance(){
if(instance == null ) {
instance= new LazySingleton();
}
returninstance;
}
}
使用方式同上。
单例模式是Javascript最基本，最有用的模式之一。它提供了一种将代码组织为一个逻辑单元的手段，这个逻辑单元中的代码通过单一的变量进行访问。
单体在Javascipt中有许多用处，可以用来划分命名空间，以减少全局变量的泛滥。还可以用在分支技术中用来处理各浏览器的差异。
Javascript中单例模式的实现方式有多种，每一种都有自身的优点或缺点。
1，对象直接量实现最基本，最简单的单体
var Singleton = {
attr1 : 1,
attr2 : 'hello',
method1 :function(){alert(this.attr2);},
method2 : function(arg){}
}
这种方式中，对象所有成员都通过Singleton加点号访问。所有成员是公开的，没有私有的。在执行到变量Singleton时，会加载(实例化)自身，即非惰性加载。
此外method1用this访问单体的其它成员会存在一些风险，因为method1的上下文不是总是指向Singleton对象。
比如当把method1作为事件监听器时，this可能指向的是dom元素，这时可能会提示undefined。
2，闭包实现私有成员的单体
var Singleton = function(){
var attr = 1, fn = function(){};
return {
method :function(){ fn(); },
getAttr :function(){ return attr; }
};
}();
这种方式中var定义私有的成员属性attr，方法fn，然后返回一个公开的接口method和getAttr。今后修改实现时，接口方法method和getAttr不变，只需修改私有的attr和fn的具体实现。使用如下
1 2 | Singleton.method(); Singleton.getAttr(); |
3，闭包实现私有成员的惰性实例化单体
var LazySingleton = function(){ var attr = 1, fn = function(){}; var obj = { method : function(){ fn(); }, getAttr : function(){ return attr; } }; function init(){ return obj; } return {getInstace: init}; }(); |
适用场合上面已经提到：对于那些必须加载大量数据的单体直到需要使用它的时候才实例化。使用方式是这样的
LazySingleton.getInstance().method(); LazySingleton.getInstance().getAttr(); |
4，又发现另一种
function singleton() {
var obj = new Object();
singleton = function() {
returnobj;
};
return obj;
}
仅在第一次时会new，这个Object泛指自定义的所有类。
4．不许用中间变量，把字符品“ABCD”倒过来
char *reverse(char *s)
{
char *r = s;//作为返回指针
char *p = s;
while(*p != '\0')
++p; //使指针p指向结束符'\0'
char *q = p-1; //使指针q指向字符串的最后一个字符
// 使用p作为交换空间逐个交换字符
while (q > s)
{
*p = *q ;
*q-- = *s ;
*s++ = *p ;
}
*p = '\0' ; // 恢复结束符
return r;
}
5．Sql中，有int，string,data字段三个类型，都加索引好么
SQL索引在数据库优化中占有一个非常大的比例， 一个好的索引的设计，可以让你的效率提高几十甚至几百倍，在这里将带你一步步揭开他的神秘面纱。
1.1 什么是索引？
SQL索引有两种，聚集索引和非聚集索引，索引主要目的是提高了SQL Server系统的性能，加快数据的查询速度与减少系统的响应时间
下面举两个简单的例子：
图书馆的例子：一个图书馆那么多书，怎么管理呢？建立一个字母开头的目录，例如：a开头的书，在第一排，b开头的在第二排，这样在找什么书就好说了，这个就是一个聚集索引，可是很多人借书找某某作者的，不知道书名怎么办？图书管理员在写一个目录，某某作者的书分别在第几排，第几排，这就是一个非聚集索引
字典的例子：字典前面的目录，可以按照拼音和部首去查询，我们想查询一个字，只需要根据拼音或者部首去查询，就可以快速的定位到这个汉字了，这个就是索引的好处，拼音查询法就是聚集索引，部首查询就是一个非聚集索引.
看了上面的例子，下面的一句话大家就很容易理解了：聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续。就像字段，聚集索引是连续的，a后面肯定是b，非聚集索引就不连续了，就像图书馆的某个作者的书，有可能在第1个货架上和第10个货架上。还有一个小知识点就是：聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个。
1.2 索引的存储机制
首先，无索引的表，查询时，是按照顺序存续的方法扫描每个记录来查找符合条件的记录，这样效率十分低下,举个例子，如果我们将字典的汉字随即打乱，没有前面的按照拼音或者部首查询，那么我们想找一个字，按照顺序的方式去一页页的找，这样效率有多底，大家可以想象。
聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致，其实理解起来非常简单，还是举字典的例子：如果按照拼音查询，那么都是从a-z的，是具有连续性的，a后面就是b，b后面就是c， 聚集索引就是这样的，他是和表的物理排列顺序是一样的，例如有id为聚集索引，那么1后面肯定是2,2后面肯定是3，所以说这样的搜索顺序的就是聚集索引。非聚集索引就和按照部首查询是一样是，可能按照偏房查询的时候，根据偏旁‘弓’字旁，索引出两个汉字，张和弘，但是这两个其实一个在100页，一个在1000页，（这里只是举个例子），他们的索引顺序和数据库表的排列顺序是不一样的，这个样的就是非聚集索引。
原理明白了，那他们是怎么存储的呢？在这里简单的说一下，聚集索引就是在数据库被开辟一个物理空间存放他的排列的值，例如1-100，所以当插入数据时，他会重新排列整个整个物理空间，而非聚集索引其实可以看作是一个含有聚集索引的表，他只仅包含原表中非聚集索引的列和指向实际物理表的指针。他只记录一个指针，其实就有点和堆栈差不多的感觉了
1.3 什么情况下设置索引
动作描述 | 使用聚集索引 | 使用非聚集索引 |
外键列 | 应 | 应 |
主键列 | 应 | 应 |
列经常被分组排序(order by) | 应 | 应 |
返回某范围内的数据 | 应 | 不应 |
小数目的不同值 | 应 | 不应 |
大数目的不同值 | 不应 | 应 |
频繁更新的列 | 不应 | 应 |
频繁修改索引列 | 不应 | 应 |
一个或极少不同值 | 不应 | 不应 |
建立索引的原则：
1) 定义主键的数据列一定要建立索引。
2) 定义有外键的数据列一定要建立索引。
3) 对于经常查询的数据列最好建立索引。
4) 对于需要在指定范围内的快速或频繁查询的数据列;
5) 经常用在WHERE子句中的数据列。
6) 经常出现在关键字order by、group by、distinct后面的字段，建立索引。如果建立的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，否则索引不会被使用。
7) 对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
8) 对于定义为text、image和bit的数据类型的列不要建立索引。
9) 对于经常存取的列避免建立索引
9) 限制表上的索引数目。对一个存在大量更新操作的表，所建索引的数目一般不要超过3个，最多不要超过5个。索引虽说提高了访问速度，但太多索引会影响数据的更新操作。
10) 对复合索引，按照字段在查询条件中出现的频度建立索引。在复合索引中，记录首先按照第一个字段排序。对于在第一个字段上取值相同的记录，系统再按照第二个字段的取值排序，以此类推。因此只有复合索引的第一个字段出现在查询条件中，该索引才可能被使用,因此将应用频度高的字段，放置在复合索引的前面，会使系统最大可能地使用此索引，发挥索引的作用。
1.4 如何创建索引
1.41 创建索引的语法：
CREATE [UNIQUE][CLUSTERED | NONCLUSTERED] INDEX index_name
ON {table_name | view_name} [WITH [index_property [,....n]]
说明：
UNIQUE: 建立唯一索引。
CLUSTERED: 建立聚集索引。
NONCLUSTERED: 建立非聚集索引。
Index_property: 索引属性。
UNIQUE索引既可以采用聚集索引结构，也可以采用非聚集索引的结构，如果不指明采用的索引结构，则SQL Server系统默认为采用非聚集索引结构。
1.42 删除索引语法：
DROP INDEX table_name.index_name[,table_name.index_name]
说明：table_name: 索引所在的表名称。
index_name : 要删除的索引名称。
1.43 显示索引信息：
使用系统存储过程：sp_helpindex 查看指定表的索引信息。
执行代码如下：
Exec sp_helpindex book1;
1.5 索引使用次数、索引效率、占用CPU检测、索引缺失
当我们明白了什么是索引，什么时间创建索引以后，我们就会想，我们创建的索引到底效率执行的怎么样？好不好？我们创建的对不对？
首先我们来认识一下DMV，DMV (dynamic management view)动态管理视图和函数返回特定于实现的内部状态数据。推出SQL Server 2005时，微软介绍了许多被称为dmvs的系统视图，让您可以探测SQL Server 的健康状况，诊断问题，或查看SQL Server实例的运行信息。统计数据是在SQL Server运行的时候开始收集的，并且在SQL Server每次启动的时候，统计数据将会被重置。当你删除或者重新创建其组件时，某些dmv的统计数据也可以被重置，例如存储过程和表，而其它的dmv信息在运行dbcc命令时也可以被重置。
当你使用一个dmv时，你需要紧记SQL Server收集这些信息有多长时间了，以确定这些从dmv返回的数据到底有多少可用性。如果SQL Server只运行了很短的一段时间，你可能不想去使用一些dmv统计数据，因为他们并不是一个能够代表SQL Server实例可能遇到的真实工作负载的样本。另一方面，SQL Server只能维持一定量的信息，有些信息在进行SQL Server性能管理活动的时候可能丢失，所以如果SQL Server已经运行了相当长的一段时间，一些统计数据就有可能已被覆盖。
因此，任何时候你使用dmv，当你查看从SQL Server 2005的dmvs返回的相关资料时，请务必将以上的观点装在脑海中。只有当你确信从dmvs获得的信息是准确和完整的，你才能变更数据库或者应用程序代码。
下面就看一下dmv到底能带给我们那些好的功能呢？
1.51 ：索引使用次数
我们下看一下下面两种查询方式返回的结果（这两种查询的查询用途一致）
①----
declare @dbid int
select @dbid = db_id()
select objectname=object_name(s.object_id), s.object_id, indexname=i.name, i.index_id
, user_seeks, user_scans, user_lookups, user_updates
from sys.dm_db_index_usage_stats s,
sys.indexes i
where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1
and i.object_id = s.object_id
and i.index_id = s.index_id
order by (user_seeks + user_scans + user_lookups + user_updates) asc
返回查询结果
②：使用多的索引排在前面
SELECT objects.name ,
databases.name ,
indexes.name ,
user_seeks ,
user_scans ,
user_lookups ,
partition_stats.row_count
FROM sys.dm_db_index_usage_stats stats
LEFT JOIN sys.objects objects ON stats.object_id = objects.object_id
LEFT JOIN sys.databases databases ON databases.database_id = stats.database_id
LEFT JOIN sys.indexes indexes ON indexes.index_id = stats.index_id
AND stats.object_id = indexes.object_id
LEFT JOIN sys.dm_db_partition_stats partition_stats ON stats.object_id = partition_stats.object_id
AND indexes.index_id = partition_stats.index_id
WHERE 1 = 1
--AND databases.database_id = 7
AND objects.name IS NOT NULL
AND indexes.name IS NOT NULL
AND user_scans>0
ORDER BY user_scans DESC ,
stats.object_id ,
indexes.index_id
返回查询结果
user_seeks : 通过用户查询执行的搜索次数。
个人理解： 此统计索引搜索的次数
user_scans: 通过用户查询执行的扫描次数。
个人理解：此统计表扫描的次数，无索引配合
user_lookups: 通过用户查询执行的查找次数。
个人理解：用户通过索引查找，在使用RID或聚集索引查找数据的次数，对于堆表或聚集表数据而言和索引配合使用次数
user_updates: 通过用户查询执行的更新次数。
个人理解：索引或表的更新次数
我们可以清晰的看到，那些索引用的多，那些索引没用过，大家可以根据查询出来的东西去分析自己的数据索引和表
1.52 ：索引提高了多少性能
新建了索引到底增加了多少数据的效率呢？到底提高了多少性能呢？运行如下SQL可以返回连接缺失索引动态管理视图，发现最有用的索引和创建索引的方法：
SELECT
avg_user_impact AS average_improvement_percentage,
avg_total_user_cost AS average_cost_of_query_without_missing_index,
'CREATE INDEX ix_' + [statement] +
ISNULL(equality_columns, '_') +
ISNULL(inequality_columns, '_') + ' ON ' + [statement] +
' (' + ISNULL(equality_columns, ' ') +
ISNULL(inequality_columns, ' ') + ')' +
ISNULL(' INCLUDE (' + included_columns + ')', '')
AS create_missing_index_command
FROM sys.dm_db_missing_index_details a INNER JOIN
sys.dm_db_missing_index_groups b ON a.index_handle = b.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats c ON
b.index_group_handle = c.group_handle
WHERE avg_user_impact > = 40
返回结果
虽然用户能够修改性能提高的百分比，但以上查询返回所有能够将性能提高40%或更高的索引。你可以清晰的看到每个索引提高的性能和效率了
1.53 ：最占用CPU、执行时间最长命令
这个和索引无关，但是还是在这里提出来，因为他也属于DMV带给我们的功能吗，他可以让你轻松查询出，那些sql语句占用你的cpu最高
SELECT TOP 100 execution_count,
total_logical_reads /execution_count AS [Avg Logical Reads],
total_elapsed_time /execution_count AS [Avg Elapsed Time],
db_name(st.dbid) as [database name],
object_name(st.dbid) as [object name],
object_name(st.objectid) as [object name 1],
SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1,
((CASE statement_end_offset WHEN - 1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)
/ 2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
WHERE execution_count > 100
ORDER BY 1 DESC;
返回结果：
执行时间最长的命令
SELECT TOP 10 COALESCE(DB_NAME(st.dbid),
DB_NAME(CAST(pa.value as int))+'*',
'Resource') AS DBNAME,
SUBSTRING(text,
-- starting value for substring
CASE WHEN statement_start_offset = 0
OR statement_start_offset IS NULL
THEN 1
ELSE statement_start_offset/2 + 1 END,
-- ending value for substring
CASE WHEN statement_end_offset = 0
OR statement_end_offset = -1
OR statement_end_offset IS NULL
THEN LEN(text)
ELSE statement_end_offset/2 END -
CASE WHEN statement_start_offset = 0
OR statement_start_offset IS NULL
THEN 1
ELSE statement_start_offset/2 END + 1
) AS TSQL,
total_logical_reads/execution_count AS AVG_LOGICAL_READS
FROM sys.dm_exec_query_stats
CROSS APPLY sys.dm_exec_sql_text(sql_handle) st
OUTER APPLY sys.dm_exec_plan_attributes(plan_handle) pa
WHERE attribute = 'dbid'
ORDER BY AVG_LOGICAL_READS DESC ;
看到了吗？直接可以定位到你的sql语句，优化去吧。还等什么呢？
1.54：缺失索引
缺失索引就是帮你查找你的数据库缺少什么索引，告诉你那些字段需要加上索引，这样你就可以根据提示添加你数据库缺少的索引了
SELECT TOP 10
[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
, avg_user_impact
, TableName = statement
, [EqualityUsage] = equality_columns
, [InequalityUsage] = inequality_columns
, [Include Cloumns] = included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;
查询结果如下：
1.6 适当创建索引覆盖
假设你在Sales表(SelesID,SalesDate,SalesPersonID,ProductID,Qty)的外键列(ProductID)上创建了一个索引，假设ProductID列是一个高选中性列，那么任何在where子句中使用索引列(ProductID)的select查询都会更快，如果在外键上没有创建索引，将会发生全部扫描，但还有办法可以进一步提升查询性能。
假设Sales表有10,000行记录，下面的SQL语句选中400行(总行数的4%)：
SELECT SalesDate, SalesPersonID FROM Sales WHERE ProductID = 112
我们来看看这条SQL语句在SQL执行引擎中是如何执行的：
1)Sales表在ProductID列上有一个非聚集索引，因此它查找非聚集索引树找出ProductID=112的记录;
2)包含ProductID = 112记录的索引页也包括所有的聚集索引键(所有的主键键值，即SalesID);
3)针对每一个主键(这里是400)，SQL Server引擎查找聚集索引树找出真实的行在对应页面中的位置;
SQL Server引擎从对应的行查找SalesDate和SalesPersonID列的值。
在上面的步骤中，对ProductID = 112的每个主键记录(这里是400)，SQL Server引擎要搜索400次聚集索引树以检索查询中指定的其它列(SalesDate，SalesPersonID)。
如果非聚集索引页中包括了聚集索引键和其它两列(SalesDate,，SalesPersonID)的值，SQL Server引擎可能不会执行上面的第3和4步，直接从非聚集索引树查找ProductID列速度还会快一些，直接从索引页读取这三列的数值。
幸运的是，有一种方法实现了这个功能，它被称为“覆盖索引”，在表列上创建覆盖索引时，需要指定哪些额外的列值需要和聚集索引键值(主键)一起存储在索引页中。下面是在Sales 表ProductID列上创建覆盖索引的例子：
CREATE INDEX NCLIX_Sales_ProductID--Index name
ON dbo.Sales(ProductID)--Column on which index is to be created
INCLUDE(SalesDate, SalesPersonID)--Additional column values to include
应该在那些select查询中常使用到的列上创建覆盖索引，但覆盖索引中包括过多的列也不行，因为覆盖索引列的值是存储在内存中的，这样会消耗过多内存，引发性能下降。
1.7 索引碎片
在数据库性能优化一：数据库自身优化一文中已经讲到了这个问题，再次就不做过多的重复地址：http://www.cnblogs.com/AK2012/archive/2012/12/25/2012-1228.html
1.8 索引实战（摘抄）
之所以这章摘抄，是因为下面这个文章已经写的太好了，估计我写出来也无法比这个好了，所以就摘抄了
人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。
笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。
在对它们进行适当的优化后，其运行速度有了明显地提高！
下面我将从这三个方面分别进行总结：
为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均表示为（< 1秒）。----
测试环境: 主机：HP LH II---- 主频：330MHZ---- 内存：128兆----
操作系统：Operserver5.0.4----
数据库：Sybase11.0.3
一、不合理的索引设计----
例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况：
---- 1.在date上建有一非个群集索引
select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 (25秒)
select date ,sum(amount) from record group by date(55秒)
select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)
---- 分析：----
date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。
---- 2.在date上的一个群集索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 （14秒）
select date,sum(amount) from record group by date（28秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）
---- 分析：---- 在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。
---- 3.在place，date，amount上的组合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 （26秒）
select date,sum(amount) from record group by date（27秒）
select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（< 1秒）
---- 分析：---- 这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条SQL没有引用place，因此也没有利用上索引；第三个SQL使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。
---- 4.在date，place，amount上的组合索引
select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)
select date,sum(amount) from record group by date（11秒）
select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）
---- 分析：---- 这是一个合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。
---- 5.总结：----
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。
一般来说：
①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考虑建立群集索引；
②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。
二、不充份的连接条件：
例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：
select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）
select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）
---- 分析：---- 在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：
外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O
在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O
可见，只有充份的连接条件，真正的最佳方案才会被执行。
总结：
1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。
2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想看更详细的信息，需用sa角色执行dbcc(3604,310,302)。
三、不可优化的where子句
1.例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：
select * from record wheresubstring(card_no,1,4)='5378'(13秒)
select * from record whereamount/30< 1000（11秒）
select * from record whereconvert(char(10),date,112)='19991201'（10秒）
分析：
where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；
如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样：
select * from record where card_no like'5378%'（< 1秒）
select * from record where amount< 1000*30（< 1秒）
select * from record where date= '1999/12/01'（< 1秒）
你会发现SQL明显快起来！
2.例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL：
select count(*) from stuff where id_no in('0','1')（23秒）
分析：---- where条件中的'in'在逻辑上相当于'or'，所以语法分析器会将in ('0','1')转化为id_no ='0' or id_no='1'来执行。
我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引；
但实际上（根据showplan）,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no上索引，并且完成时间还要受tempdb数据库性能的影响。
实践证明，表的行数越多，工作表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分开：
select count(*) from stuff where id_no='0'select count(*) from stuff where id_no='1'
得到两个结果，再作一次加法合算。因为每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。
或者，用更好的方法，写一个简单的存储过程：
create proc count_stuff asdeclare @a intdeclare @b intdeclare @c intdeclare @d char(10)beginselect @a=count(*) from stuff where id_no='0'select @b=count(*) from stuff where id_no='1'endselect @c=@a+@bselect @d=convert(char(10),@c)print @d
直接算出结果，执行时间同上面一样快！
---- 总结：---- 可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。
1.任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。
3.要善于使用存储过程，它使SQL变得更加灵活和高效。
从以上这些例子可以看出，SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
6．打印出1到100的素数
public class TestSu { public static void main(String[] args) { int j; for (int i = 2; i <= 100; i++) // 1不是素数，所以直接从2开始循环 { j = 2; while (i % j != 0) { j++; // 测试2至i的数字是否能被i整除，如不能就自加 } if (j == i) // 当有被整除的数字时，判断它是不是自身 { System.out.println(i); // 如果是就打印出数字 } } } }
质数(又称为素数）
1.就是在所有比1大的整数中,除了1和它本身以外,不再有别的约数,这种整数叫做质数或素数.还可以说成质数只有1和它本身两个约数.
2.素数是这样的整数,它除了能表示为它自己和1的乘积以外,不能表示为任
何其它两个整数的乘积.
所谓质数或称素数,就是一个正整数,除了本身和 1 以外并没有任何其他因子.例如 2,3,5,7 是质数,而 4,6,8,9 则不是,后者称为合成数或合数.从这个观点可将整数分为两种,一种叫质数,一种叫合成数.（有人认为数目字 1 不该称为质数）著名的高斯「唯一分解定理」说,任何一个整数.可以写成一串质数相乘的积.
6．在高并发的情况下，如何确保库存足够下订单
减库存思路，库存加锁，库存足够就下订单，库存不够就不下订单
下单以及订单处理流程描述
- 下单过程
- 预订者浏览某个已发布的会议；
- 进入会议的详情页面，该页面显示了所有可预订的座位分类信息；
- 预订者选择好要预订的座位分类，录入每个分类的预定数量；
- 预订者点击提交按钮，提交下单请求到Server端；
- Server端Controller提交处理订单的命令到分布式消息队列（EQueue），然后后台的Command Processor就可以消费该命令并异步处理订单了。核心处理步骤：
- 生成订单（初始状态）；
- 扣减库存（内部有预扣逻辑）；
- 更新订单状态；
- Server端Controller发送命令后，立即重定向页面到查单订单处理结果页面，该页面会以轮训的方式查看订单处理结果；
- 如果下单成功（库存足够），预订者被导航到支付页面进行支付；预订者可以选择支付，也可以放弃支付；
- 如果下单失败（库存不足），则提示用户下单失败，因为库存不足；
- 如果轮训等待超时，则告诉用户暂时无法知道订单处理状态，然后当前页面继续定时（5s）轮训订单处理结果；
- 如果支付成功，则提示预订者订单处理完成，交易完成；
- 如果拒绝支付，则关闭订单；
- 如果超过规定时间（15分钟）未支付，则视作订单已过期，系统自动回收订单所预定的座位；
上面用文字描述了整个下单和订单处理以及支付的过程，而我们实际关心的核心还是服务端对订单处理的过程。所以下面我们就看看如何来进行代码实现。
订单处理Saga流程图
Conference案例中，服务端处理订单是采用CQRS Saga流程的方式实现的。一个Saga流程是一个事件驱动的业务流程，它的周期可能比较长，因为流程中某些步骤需要用户参与的。上图描述了服务端处理订单的正常处理逻辑。为什么说是正常处理逻辑，因为实际的代码比上面的流程图还要复杂一点，上面的流程图中没有画出库存不足、用户拒绝付款、或者付款超时等情况的处理。我觉得这些特殊的情况，只要读者自己看一下代码就能很快理解了。只要我们能够把正常的逻辑搞清楚，那我们心里就对整个订单处理的流程有了解了。
上图中，聚合根之间棕色的箭头表示Command，蓝色的箭头表示Event。Order Process Manager表示一个无状态的Saga流程管理器，它负责协调其他有状态的聚合根，负责整个订单处理的流程控制逻辑。从代码表现上来看，它的任务就是响应Event，然后发出下一个Command。然后Order, Conference, Payment三个聚合根分别表示订单、会议、支付。这三个聚合根分别封装自己的状态和业务规则。
订单处理之减库存的设计思路
库存信息在哪里维护
大家都知道，电子商务系统，订单处理时，核心的环节就是减库存。那我们首先要思考的问题是，库存在哪里维护呢？在我看了微软的Conference案例的代码后，发现它的库存信息是在Registration（订单处理）的上下文中维护的。当ConferenceManagement（会议管理）上下文中，对会议的库存有修改时，会通过事件异步同步到订单处理上下文。我在思考它这样设计的理由是什么，我能想到的唯一理由是，这样的好处是减库存时，就只需要在Registration当前的上下文中处理即可，这样就不需要依赖会议管理上下文了。但代价就是需要从会议管理上下文同步库存信息。
我的思考：
我个人认为，库存信息还是应该在会议管理上下文中维护比较合理，因为会议管理上下文的职责就是维护会议的基本信息以及会议的座位类型的实体信息。如果我们的库存管理没有独立为独立的上下文，那最合理的维护地方就是会议管理上下文。这样，一份数据就只需要在一个地方维护，不需要同步。然后当订单处理上下文需要减库存时，可以通过远程调用或者异步消息通信的方式来实现上下文之间的交互。
但实际的电商系统，比如像淘宝这种，由于库存管理也是一块复杂的业务，所以一般会独立出一个上下文，叫库存中心。然后这个库存中心独立于商品中心以及订单中心。当订单中心要求减库存时，只需要和库存中心进行交互即可。这样的方式，会让系统的职责更明确，商品中心不需要关心商品的库存了，只需要关注商品本身的属性信息即可。然后，本案例由于只是案例，所以没有独立出库存中心，即库存上下文。所以会议座位的库存管理放在会议管理上下文中。
库存怎么预扣
明确了库存所属的上下文后，我们接下来思考怎么实现减库存。减库存主要的问题是，在并发减库存的情况下，可能会出现超卖的情况。为了解决超卖的问题，一般主流的做法是采用预扣库存的方式，类似分布式事务的二阶段提交的过程。预扣的意思是先预扣库存，如果预扣成功，就可以通知用户下单成功，然后就可以让用户去付款了；如果预扣时发现库存不足，则提示用户库存不足。
然后，虽然是预扣，但因为大家同时预扣同一个会议聚合根的座位库存，所以还是会产生并发问题。但由于我们操作的是同一个聚合根，所以ENode框架帮我们确保不会有并发问题。我们先看看Conference聚合根内部关于座位的库存管理的设计实现。
如上面的代码所示，Conference聚合根里聚合了所有的座位类型子实体，每个座位类型维护了座位的名称、价格、数量；然后Conference聚合根里还维护了所有的预定记录，这个应该不难理解。MakeReservation方法就是Conference聚合根对外提供预定座位支持的方法。该方法接收一些要预定的项，以及一个预定的ID，表示这次预定是谁（实际上就是订单ID）要预定。该方法内部的逻辑是：
- 判断当前会议是否没有发布，如果没有发布，那是不允许预定的；
- 判断这个预定（reservationId）是否是重复预定，如果重复，也会抛出异常；为什么会出现重复预定，因为订单处理上下文是通过发送命令的方式来通知Conference进行预定的，而由于是分布式消息队列（EQueue），所以命令可能会被重复执行。
- 检查预定的座位明细是否为空，如果为空，就认为是无效的预定，抛异常；
- 接下来就是循环处理每个预定项，先检查预定项本身需要预定的数量是否无效（小于等于0），如果无效，则抛出异常；再从Conference聚合根里找到当前要预定的座位类型子实体；然后计算当前的座位类型是否有足够的可用库存，GetTotalReservationQuantity方法就是计算当前该座位类型总共已经预定的总数。如果库存不足，则直接抛出异常。当然这里直接抛出异常可能还是太草率了一点。因为真正的电子商务系统，应该会明确提示用户，哪些商品库存不足，是否要修改订单只购买剩余的库存。本案例为了让代码不会太复杂，所以简化了功能。只要被预定的座位类型出现一个库存不足，就认为下单失败了。
- 当所有的预定项都处理完成后，就可以产生“已预定”的领域事件了。注意，这里我们产生事件的时候，同时把当前每个座位类型剩余的库存数量也放在领域事件里了。这样的好处是，当Q端的Event Handler在更新Conference的读库时，不需要再计算了，直接用Update语句更新DB即可。这个设计大家可以参考下，这样的设计，体现了Domain中封装了一切数据更新的业务规则判断和逻辑处理，然后通过事件的方式通知Domain外部当前事件发生后，聚合根的当前状态（一定是第一手数据，不会是脏数据）是什么。这样外部的Event Handler的逻辑就非常简单了，都只需要简单的用Update语句更新DB即可（不用动脑子，呵呵）。
并发问题的处理
Domain不会考虑并发这种技术问题，它只关心自己的业务规则和数据一致性，完全从业务角度来写代码。我们可以看到Conference聚合根里封装了很多的规则和逻辑。然后Conference聚合根产生的Event持久化到EventStore时的并发问题，ENode框架会帮我们解决，应用开发者不用担心了。如果大家关心是怎么解决的，可以去看一下ENode我以前写过的一些介绍，核心思路是乐观并发控制（通过聚合根版本号）+ 自动重试的机制，这里我就不展开了。
通过上面的设计，我们知道每次预扣时总是会判断当前可用的库存，并且已经考虑了其他已经预扣了的订单；这就从业务逻辑上保证了不会出现超卖；然后ENode框架解决了并发问题，所以最后我们可以确保一定不会出现超卖的情况。
用户付款后怎么真正减库存
当预扣成功后，用户就会去付款，假如付款成功了，那系统就会自动提交之前的预扣记录，做真正的减库存。我们来看看逻辑是怎么样的：
CommitReservation方法是Conference聚合根用来提供支持提交减库存的方法。它接收一个要提交减库存的reservationId，通过该ID，先找到之前它预定的所有预定项，然后产生一个事件，事件中包含每个预定项所对应的座位类型的扣除后的库存数量，最后产生领域事件。然后聚合根内部会响应领域事件，更新聚合根自己的状态。我们在Commit阶段是不用担心数据有什么问题的，因为肯定是之前预扣过了，只要预扣记录存在，那就可以放心的做减库存逻辑的。这是我们通过业务上的2PC协议保证的。
代码很直接，就是先删除预定记录，并把预定记录的每个明细对应的座位类型的库存更新即可。然后，我们的读库的更新也是这样的逻辑，只是更新的是读库DB而已。
7．sql根据当前日期，查询所在周的周一至周日的日期，所在月的第一天到最后一天，所在年的第一天到最后一天
#当年第一天：
SELECT DATE_SUB(CURDATE(),INTERVALdayofyear(now())-1 DAY);
#当年最后一天：
SELECT concat(YEAR(now()),'-12-31');
#当前week的第一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) + 1 DAY);
#当前week的最后一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) - 5 DAY);
#前一week的第一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) + 8 DAY);
#前一week的最后一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) + 2 DAY);
#前两week的第一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) + 15 DAY);
#前两week的最后一天：
select date_sub(curdate(),INTERVALWEEKDAY(curdate()) + 9 DAY);
#当前month的第一天：
SELECTconcat(date_format(LAST_DAY(now()),'%Y-%m-'),'01');
#当前month的最后一天：
SELECT LAST_DAY(now());
#前一month的第一天：
SELECT concat(date_format(LAST_DAY(now() -interval 1 month),'%Y-%m-'),'01');
#前一month的最后一天：
SELECT LAST_DAY(now() - interval 1month);
#前两month的第一天：
SELECT concat(date_format(LAST_DAY(now() -interval 2 month),'%Y-%m-'),'01');
#前两month的最后一天：
SELECT LAST_DAY(now() - interval 2 month);
#当前quarter的第一天：
selectconcat(date_format(LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM CURDATE()),1) + intervalQUARTER(CURDATE())*3-3 month),'%Y-%m-'),'01');
#当前quarter的最后一天：
select LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM CURDATE()),1) + interval QUARTER(CURDATE())*3-1month);
#前一quarter的第一天：
selectconcat(date_format(LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM CURDATE()),1) + intervalQUARTER(CURDATE())*3-6 month),'%Y-%m-'),'01');
#前一quarter的最后一天：
select LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM CURDATE()),1) + intervalQUARTER(CURDATE())*3-4 month);
#前两quarter的第一天：
selectconcat(date_format(LAST_DAY(MAKEDATE(EXTRACT(YEAR FROM CURDATE()),1) + intervalQUARTER(CURDATE())*3-9 month),'%Y-%m-'),'01');
#前两quarter的最后一天：
select LAST_DAY(MAKEDATE(EXTRACT(YEAR FROMCURDATE()),1) + interval QUARTER(CURDATE())*3-7 month);
1．说一下SSM的流程
2．Java缓存技术常用的有哪些？
OSCache OSCache是个一个广泛采用的高性能的J2EE缓存框架，OSCache能用于任何Java应用程序的普通的缓存解决方案。 OSCache有以下特点： 缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。 拥有全面的API--OSCache API给你全面的程序来控制所有的OSCache特性。 永久缓存--缓存能随意的写入硬盘，因此允许昂贵的创建（expensive-to-create）数据来保持缓存，甚至能让应用重启。 支持集群--集群缓存数据能被单个的进行参数配置，不需要修改代码。 缓存记录的过期--你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不需要时）。 官方网站 http://www.opensymphony.com/oscache/ Java Caching System JSC(Java Caching System)是一个用分布式的缓存系统，是基于服务器的java应用程序。它是通过提供管理各种动态缓存数据来加速动态web应用。 JCS和其他缓存系统一样，也是一个用于高速读取，低速写入的应用程序。 动态内容和报表系统能够获得更好的性能。 如果一个网站，有重复的网站结构，使用间歇性更新方式的数据库（而不是连续不断的更新数据库），被重复搜索出相同结果的， 就能够通过执行缓存方式改进其性能和伸缩性。 官方网站 http://jakarta.apache.org/turbine/jcs/ EHCache EHCache 是一个纯java的在进程中的缓存，它具有以下特性：快速，简单，为Hibernate2.1充当可插入的缓存，最小的依赖性，全面的文档和测试。 官方网站 http://ehcache.sourceforge.net/ JCache JCache是个开源程序，正在努力成为JSR-107开源规范，JSR-107规范已经很多年没改变了。这个版本仍然是构建在最初的功能定义上。 官方网站 http://jcache.sourceforge.net/ ShiftOne ShiftOne Java Object Cache是一个执行一系列严格的对象缓存策略的Java lib，就像一个轻量级的配置缓存工作状态的框架。 官方网站 http://jocache.sourceforge.net/ SwarmCache SwarmCache是一个简单且有效的分布式缓存，它使用IP multicast与同一个局域网的其他主机进行通讯，是特别为集群和数据驱动web应用程序而设计的。 SwarmCache能够让典型的读操作大大超过写操作的这类应用提供更好的性能支持。 SwarmCache使用JavaGroups来管理从属关系和分布式缓存的通讯。 官方网站 http://swarmcache.sourceforge.net TreeCache / JBossCache JBossCache是一个复制的事务处理缓存，它允许你缓存企业级应用数据来更好的改善性能。缓存数据被自动复制， 让你轻松进行JBoss服务器之间 的集群工作。JBossCache能够通过JBoss应用服务或其他J2EE容器来运行一个MBean服务，当然，它也能独立运行。 JBossCache包括两个模块：TreeCache和TreeCacheAOP。 TreeCache --是一个树形结构复制的事务处理缓存。 TreeCacheAOP --是一个“面向对象”缓存，它使用AOP来动态管理POJO(Plain Old Java Objects) 注：AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向方面编程。 官方网站 http://www.jboss.org/products/jbosscache WhirlyCache Whirlycache是一个快速的、可配置的、存在于内存中的对象的缓存。它能够通过缓存对象来加快网站或应用程序的速度， 否则就必须通过查询数据库或其他代价较高的处理程序来建立。
ArrayList和LinkedList区别
1.ArrayList是实现了基于动态数组的数据结构，LinkedList基于链表的数据结构。
2.对于随机访问get和set，ArrayList觉得优于LinkedList，因为LinkedList要移动指针。
3.对于新增和删除操作add和remove，LinedList比较占优势，因为ArrayList要移动数据。
3．jsp和servlet的区别
jsp和servlet都属于j2ee13规范，servlet是运行在服务端的Java程序，动态生成web内容，但是如果仅仅使用servlet来输出html则是一句一句地输出，为开发和维护带来了极大的不便。而jsp可以这么理解，可以在html中添加Java代码，所以页面渲染结果可以直接使用Dreamweaver等编辑器直接更改，更简单快捷，而不用维护Java类中的代码。实现了解耦合。
而jsp的本质还是servlet，它只不过是利用了另外一套规则写的servlet，它运行也是需要先编译成Java代码，然后进行输出的，这些操作都是jsp容器完成的，比如一个jsp在tomcat中被编译，则会生成相应的Java类。
4．拦截器和监听器的区别（Servlet,过滤器，监听器，拦截器的区别）
5．Mybaitis的配置流程和注意事项
一、导包（用eclipse开发）
1、如果你新建的是普通的project，需要在工程目录下，新建一个文件夹（一般为lib），然后需要手动导包，具体操作是：选中包右键-Build Path-add to Build Path。之前的文件夹不能删除，因为它实际上加载的是这些包的路径。
2、如果你新建的是web工程，只需要把相关包放到WEB-INF/lib中即可，它会自动导包，同样lib里的包不能删除。
二、XML文件配置
1、该配置文件名可以自定义，放置的路径也可以自定义，但是如果你不是放在src的根路径下，比如放在src/config/mybatis.xml，在创建SqlSessionFactory实例时，Resources.getResourceAsReader("config/mybatis.xml")，config前不能加“/”，如果放在src根路径下，这里直接写文件名即可。
2、配置文件里配置项目是有先后顺序的，依次是：properties,settings,typeAliases,typeHandlers,objectFactory,objectWrapperFactory,plugins,environments,databaseIdProvider,mappers，那个选项不配置，它的位置空出来，但顺序必须遵循，否则会报错。
3、properties选项，可导入外部以properties结尾的配置文件。通常会将数据库的连接信息放在该配置文件里，这时在配置dataSource时，value=“${driver}”，这种形式，此处driver对应的就是配置文件中driver = com.mysql.jdbc.Driver
4、在配置mapper时，有几种方式，分别是resource、url、class、package
resource形式：
<mappers>
<mapperresource="com/tiantian/mybatis/model/BlogMapper.xml"/>
</mappers>
这个路径是你xml映射文件的路径包名+文件名。
url形式：
<mappers>
<mapperurl="file:///var/mappers/BlogMapper.xml"/>
</mappers>
这个路径对应的是网络上了某个文件，注意file:// 前缀 +路径+文件名
class形式：
<mappers>
<mapper class="org.mybatis.builder.BlogMapper"/>
</mappers>
这个class实际上是接口，写的是接口的全名。
package形式：
<mappers>
<package name="org.mybatis.builder"/>
</mappers>
5、实际项目中采用最多的是面向接口编程，也就是一个接口对应一个XML映射文件，如果让接口和映射文件对应呢？答案是XML映射文件中的mapper namespace="com.mybatis.inter.IUserOperation"，这个namespace中一定是接口的全名，不能是别名、简名，否则运行时会报错。一般我们会把接口名和映射文件名写成一样的，而且在同一个包下，所以感觉namespace就是xml文件的全名。
6．对Shiro权限框架了解多少
最近加入了gxpt项目组，被安排做权限模块，所以也有幸第一次接触到了Shiro框架。让我们来一起领略Shiro的风采吧。
什么是Apache Shiro？
ApacheShiro（发音为“shee-roh”，日语“堡垒（Castle）”的意思）是一个强大易用的Java安全框架，提供了认证、授权、加密和会话管理功能，可为任何应用提供安全保障 - 从命令行应用、移动应用到大型网络及企业应用。
你可以用 Apache Shiro做下面的事情：
·
-
- 验证用户
- 对用户执行访问控制，如：
- 判断用户是否拥有角色admin
- 判断用户是否拥有访问的权限
- 在任何环境下使用 Session API
- 可以使用多个用户数据源。例如一个是oracle用户库，另外一个是mysql用户库
- 单点登录（SSO）功能
- “Remember Me”服务 ，类似购物车的功能，shiro官方建议开启
Shiro要想做成以上的事情，主要依赖于4大API：
·
-
- Authentication —— 认证，用户身份识别，常被称为用户“登录”，who are you?
- Authorization —— 授权，访问控制过程，决定“谁”访问“什么”，who can do what?
- Session Management —— 会话管理，用户session管理器，用户相关的时间敏感的状态
- Cryptography —— 密码加密，把JDK中复杂的密码加密方式进行封装，保护或隐藏数据防止被偷窥
Shiro还支持一些辅助特性，如Web应用安全、缓存、单元测试和多线程，它们的存在强化了上面提到的四个要素。
为什么要用Shiro？
虽然目前有其他安全框架，比如 JAAS，Spring Security，但是仍有令人信服的理由让你选择Shiro：
·
-
- 易于使用 —— 可以让新手都能很快上手，应用安全的开发与管理将不再是一种痛苦
- 灵活性 —— 可以工作在任何应用环境中。虽然它工作在Web、EJB和IoC环境中，但并不依赖这些环境。既不强加任何规范，也无需过多依赖。
- Web能力 —— 对Web应用的支持很神奇，允许你基于应用URL和Web协议（如REST）创建灵活的安全策略，同时还提供了一套控制页面输出的JSP标签库。
- 热插拔 —— Shiro干净的API和设计模式使它可以方便地与许多的其他框架和应用进行无缝集成。
Shiro大体框架
要想快速了解Shiro，必须先从整体上去了解它，先说说它的高度概括框架：
Shiro包含三个核心组件：Subject,SecurityManager 和 Realms。具体来说：
Subject是与程序进行交互的对象，可以是人也可以是服务或者其他，通常就理解为用户。
所有Subject 实例都必须绑定到一个SecurityManager上。我们与一个 Subject 交互，运行时shiro会自动转化为与 SecurityManager交互的特定 subject的交互。
SecurityManager 是 Shiro的核心，初始化时协调各个模块运行。
当SecurityManager协调完毕，SecurityManager 会被单独留下，且我们只需要去操作Subject即可，无需操作SecurityManager 。 但是我们得知道，当我们正与一个 Subject 进行交互时，实质上是 SecurityManager在处理 Subject 安全操作。
Realms在 Shiro中作为应用程序和安全数据之间的“桥梁”或“连接器”。
它获取安全数据来判断subject是否能够登录，subject拥有什么权限。有点类似DAO。在配置realms时，需要至少一个realm。而且Shiro提供了一些常用的 Realms来连接数据源，如LDAP数据源的JndiLdapRealm，JDBC数据源的JdbcRealm，ini文件数据源的IniRealm，properties文件数据源的PropertiesRealm等等。我们也可以插入自己的 Realm实现来代表自定义的数据源。像其他组件一样，Realms也是由SecurityManager控制
Shiro整体框架
简单了解了一下大体的框架，现在让我们一起来目睹Shiro的“芳容”吧：
- Subject (org.apache.shiro.subject.Subject):
简称用户，解释同上。 - SecurityManager (org.apache.shiro.mgt.SecurityManager)
如上所述，SecurityManager是shiro的核心，协调shiro的各个组件。- Authenticator (org.apache.shiro.authc.Authenticator)：
用户身份验证组件，登录控制。
- Authenticator (org.apache.shiro.authc.Authenticator)：
- Authentication Strategy (org.apache.shiro.authc.pam.AuthenticationStrategy)
如果存在多个realm，则接口AuthenticationStrategy会确定什么样算是登录成功（例如，如果一个Realm成功，而其他的均失败，是否登录成功？）。 - Authorizer (org.apache.shiro.authz.Authorizer) ：
访问控制组件，决定subject能拥有什么样角色或者权限。 - SessionManager (org.apache.shiro.session.SessionManager) ：
创建和管理用户session。通过设置这个管理器，shiro可以在任何环境下使用session。- SessionDao (org.apache.shiro.mgt.eis.SessionDao)：
代表SessionManager执行Session持久化(CURD)操作。
- SessionDao (org.apache.shiro.mgt.eis.SessionDao)：
- CacheManager (org.apahce.shiro.cache.CacheManager) ：
缓存管理器，可以减少不必要的后台访问。提高应用效率，增加用户体验。 - Cryptography(org.apache.shiro.crypto.*) :
Shiro的api大幅度简化java api中繁琐的密码加密。 - Realms(org.apache.shiro.realm.Realm) ：
程序与安全数据的桥梁
1．Linux命令会用吗
Ls、cd 、cp、mv、mkdir、vi、find、tar、chkconfig、service、cat、less
有了这些，就能应付一下了。
面试时说写几个常用的
vi编辑器命令之类的吧
你在linux下安装，配置一套java+tomcat+mysql，再简单调试一下bug，需要用到哪些命令? 记住这些即可。
不过，窃以为，如果你招聘的是java开发，而不是维护这块，linux命令不会考很多吧。
你说的这些，有些难了吧，配置java的话，就要分别说是什么工程，分别打对应的包，这时候至少要会tar命令，tomcat的直接下载对应版本，解压即可，将包放在webapp下，cd 到/bin目录，执行./start命令加载工程。同样下载lunux下的mysql，用tar或者gz解压 后，要配置相应的配置文件，这时候要会vi命令 等等吧
楼主，可以知道点简单的命令就可以 如 cd、mkdir、tar、chmod、等等。
Linux 常用的操作命令肯定要会，当然了，涉及 Linux 系统管理的应该不作要求。
普通的 Shell 脚本肯定要会写。
2.手机app应用，微信小程序了解多少
1．多少K的java web程序员应该懂多线程和jvm优化？
前两天面试了一个四年工作经验的Java工程师，挺失望的。工作换了四五家，大多浅尝则止，基础太差了。面试别人，一般基于其项目经历和简历的技能栈交流。没想到，这次交流成了授课了。“大处着眼，小处落手”，一个技术人员既要具备技术视野，也要理解技术细节。
比较有感触的有下面几个问题。首先，我问了一个很多人平时意识不到的问题：一个.java文本文件，是如何运行起来的？本来是想检查下对Jave程序语言的运行机制的理解。如果回答可以就可以切入到虚拟机和java程序性能调优。没想到大失所望，该同学对此几乎没有概念。接下来，我问，HashMap的内部实现，不清楚，key是否可以是null，不知道。让其写一个简单的栈Stack类，实现基本的存取功能，我把结构都写了，让他下笔，写不出来。本来是考察对基本数据结构的理解，可能的话切入内存泄露。
到此，我已经基本确认该同学之前基本不写代码了。但他应聘的是中高级工程师，本着负责的态度。该问的还得继续。看项目经历吧，有个做OA系统的经验，熟悉Jbpm，看简历写着熟悉设计模式。好吧，我问：如果让你设计一个简单的流程引擎，你怎么设计，大概会用到什么设计模式。我想着，怎么着，你也应该知道责任链模式和观察者模式吧，退一步讲，一个好的系统，工厂模式、建造者模式不可能没有。对方一脸懵逼，说，没去了解过。说实在的，当时真的是有点不耐烦了。
看到简历有mybatis技能，问动态sql拼装有哪些常用标签，回答差强人意。问得深一点：平时使用mybatis基本都是使用接口声明，然后注入直接调用接口方法，即可完成数据库操作。有没有疑惑过，为什么没看到实现该接口的类，就可以调用方法。要知道接口是不能实例化的。本意是考察对代理类生成（代理模式）的理解，不出所料，完全没有概念。随后简单问了下数据库，居然不知道索引是一棵树，，，
随后草草收场。
简单描述本次面试经历，我是觉得该面试者是一个典型。“大处着眼”，他不知道技术和框架出现的背景是什么，技术视野窄，不知道用什么技术解决实际问题，也没有关心前沿技术（分布式、服务化、大数据）；“小处着手”，他没有探究内部原理的好奇心和意识，小一点说连“点进去JDK类的实现方法”的欲望都没有。
我不知道这样技术深度和广度都没有的水平，怎么能实现他所说的“三年成为一个优秀的架构师”的愿望。
感慨万千啊。
###
多线程和虚拟机。实际工作中，大部分程序员可能几乎不用，但这两项技能是你面试所谓高级工程师的敲门砖，也是你在机会到来的时候能否顶上去的弹药库。很多人，把这两部看的太高深，望而却步，我觉得一个重要原因就是大部分博客和书籍写的太差，只讲结果不谈背景。比如，讲到虚拟机，上来就以hotspot为例，内存模型，各种分区、回收算法；讲到多线程，上来就各种synchronized关键字、各种锁、线程池怎么用。新手看到就蒙了。要知道，一切技术的出现都是有背景的。所有技术的出现都是基于计算机原理和体系结构的。为了解决特定问题，人们基于计算机理解的语言才创造了各种解决问题的方法，也就是说这些解决方案不过是践行某种思想的一种体现罢了。
先说虚拟机，我们都知道Java程序运行在虚拟机上，虚拟机又和操作系统打交道，最终通过二进制指令操纵电子电路运行。完成数据的读取，存储，运算和输出。
虚拟机在加载.class文件的时候，会在内存开辟一块区域“方法区”，专门用来存储类的基本信息，同时在“堆”区为这些类生成一个Class对象，作为类的“镜像”或“模具”，为反射提供基础。程序运行过程中，对象不断的生成和死亡，有的朝生暮死（大多数对象都这样，最常见的是方法内部生成的临时对象），有的壮年而亡，有的长命百岁，有的长生不死除非世界毁灭（虚拟机关闭，典型的如servlet）。对象生要吃喝，死了得埋，所以虚拟机就不停的申请内存、回收内存。对象的生成方法很多，new、反射等，对象回收的方法也有很多，这就是GC，标记-清除、复制、标记-整理等等。
垃圾回收，顾名思义，得确定垃圾是什么、在那里、如何回收。对象的生命周期不同，回收的方法不一样。假如让你设计垃圾回收，你该怎么做？大多数人都会想到，后台启动一个线程，隔一段时间（或达到某种状态，去堆用掉了80%），扫描垃圾对象，然后清除，然后继续执行原来的程序（串行收集器）。恭喜你，你也可以设计虚拟机了。但不幸的是，情况往往比你想象的复杂。效率、安全性、对原程序的影响，都是你要考虑的。人们最先发现，对象生命周期不同，用同一种GC方法，实在是效率差，怎么办？就如hotspot的方案，堆区根据对象生命周期不同，分成了Eden、Survivor0、Survivor1和Old区。每个区采用了不同的清理算法。多核的出现，自然人们会想到并行收集器，即多个回收线程一起跑；为了将对原程序影响降到最低（STW），又出现了并发收集器。这些，本质上，就是抽象分层思想的体现。类似于，重构代码中的，抽离属性和抽离方法。这种思想，我认为是计算机最重要的思想。可以讲三天三夜。如分布式服务中，根据业务模型，分拆用户服务、商品服务、订单服务。
到此为止，虚拟机优化就涉及到两大方面，各个区的大小怎么划分最优、垃圾回收算法怎么选择最优。直接点，就是JVM参数调整。但关键在于，给你一个系统（可能是一个陌生的系统，我说的陌生可能就是你开放的系统，只是每个人负责的只是一个模块，对系统整体不熟悉），你怎么样能恰当估算系统业务情况，进而有针对性的收集系统数据，根据场景，确定优化的方向点，然后找到这个点对应的虚拟机参数，调整参数，或者，优化代码。注意，一切优化必须基于业务模型。不同业务系统、甚至同一套系统不同用户基数调整的方向都不一样。平时，我遇到的情况大概分为两种，一种是堆的问题，比如代码问题导致List或map越来越大，或者是string使用不当，造成频繁old gc；某个外部组件调用，生成大量代理类无法销毁。还有一种是线程栈，线程阻塞甚至死锁的问题。多线程使用不当，比不使用还坑爹。
多线程，任何一个程序员都知道，但实际工作中，大部分程序员每天面对的基本是业务问题的CRUD和Bug定位，貌似没有直接接触多线程的机会。
大家知道程序运行的时候，最关键的是内存和cpu，而cpu运算的时候，是要从内存取值，当然很多时候是从缓存取值的，然后放入寄存器，参与运算，得到结果，先放入寄存器，然后放入内存。程序执行的指令也放在寄存器，它记录了当前程序执行的地址。用一句话概括：程序=数据结构+算法。CPU运算需要知道，我要执行什么程序、我的程序数据怎么获取。
大家应该看出问题来了吧？首先，线程执行是语言指令寄存器的，也就是当你切换线程的时候，得从虚拟机的程序计数器（PC）把该线程的执行指令放到指令寄存器，当然线程涉及的其他资源也要切换，比如IO设备。这些都是需要耗费资源的，这就是所谓的线程上下文切换。大学时候，记得很清楚的一句话：线程是CPU执行的最小单位。当时没怎么理解，后来想CPU执行程序，总得知道执行什么吧，那得准备指令寄存器的值，原材料得有吧，就可能涉及文件系统、网络资源吧，运算结果得输出到内存、文件或者网络吧。这些都是资源啊。所以，线程创建是一笔很大的开销。当然，如果你就一个线程，那就无所谓了，反正资源都是我的，想怎么用就怎么用。所以，很多时候，单线程比多线程快。
很多面试宝典，有这么一道题：Java线程的start和run方法有什么区别？通过我上面关于线程执行的分析，应该一目了然。我用一个做饭的例子说明，start需要你买菜、准备锅碗瓢盆油盐酱醋、洗菜切肉，而run则是往锅里放油放菜炒。大家可以看到，Thread源码的start0是个native方法，也就是资源准备是虚拟机帮你做了。你不用管我菜是怎么买的、价钱多少。当然了，如果菜市场很远，一直没买到，或者排队很长，甚至被别人插队，那你这顿饭就一直做不上。这就是所谓的线程阻塞了。如果两个厨师都在做饭，一个拿着酱油想要醋，一个拿着醋想要酱油，互不相让，就出现所谓的死锁。不好意思，扯远了。关于start和run，如果把方法名改为：applyResourceAndPerformAction和doConcreteActions，是不是很容易理解？很多人面试的时候，背一下宝典，原理根本不清楚。你能指望他处理复杂问题？线程必须的资源虚拟机帮你做了，你需要的就是告诉线程你具体做什么，所以实现线程的几种方式就有了，1、继承Thread目的重写run方法；2、实现Runnable接口，实现run方法；3实现Callable接口，回调获取线程结果。1使用了继承，2和3使用了组合，内部持有了你所实现的类，更加灵活。你看，多用组合少用继承的原则就这么体现了。
第二点，上面说到了，一个数值，进入CPU运算，经过了内存、多级缓存、寄存器，也就是说，当多线程运算同一个值的时候，是需要把值从主内存拿到该线程工作内存（寄存器）中的，当一个线程计算完毕（CPU首先把运算结果放到寄存器），还没刷新到主内存的时候，另一个线程从主内存取到的是旧值。JVM运行的每个线程都有自己的线程栈，不同线程运行的时候，都要复制主内存的一份副本到工作内存。怎么保证每个线程拿到的数据是最新的，这就是同步机制。volatile和synchronized，就是为了解决这个问题的。
首先，谁都能想到的最直接的办法就是：共享变量同一时刻只允许有一个线程操作。这样就保证了所有线程要么拿不到值，要么拿到的值是“纯粹”的。于是有了synchronized，用来告诉虚拟机：这个地方是圣地，不允许多个人同时涉足。这里有一把锁，必须拿到锁才能进入，其他人要想进来必须等待。Java中的锁，可以是this对象、方法、类，也可以是声明的某个变量。锁的范围，可以是小块代码段，可以是整个方法区，甚至是所有方法。一定要注意锁和锁的范围，这是两个维度的事情。虚拟机会在锁对象和线程之间建立联系，其他线程跑到锁对象的时候，会看到：哦，其他哥们已经来了，我先等着吧。特别注意，不要以为对象和类的定义一样，不过是属性和方法的集合，类和对象是两回事。类似模具和产品的关系。虚拟机生成一个对象，这个对象有很多额外信息，起码有对象内存地址你是知道的吧？所以，要标识这个对象当前被哪个线程占有，是一件很容易的事情。感兴趣的同学，可以去看看对象在内存中的布局。
我们很快发现，上面的方法有点粗暴，也不够灵活。很多时候，我们不关心共享值在被谁操作，我只关当前这个值“到底”是什么。所以，就有了volatile，大部分博客提到volatile，就一句话：保证可见性，不保证原子性。这什么鬼？实际上，如果一个共享变量声明为volatile，等于告诉虚拟机控制的所有线程：这个变量有点帅，要请他出山必须亲自去他老家——主内存去请，回来的时候也要尽快送回老家。所以，CPU计算的时候要从主内存取值，计算完毕，直接就写入主内存，不会写到高速缓存了。这就是所谓的“可见性”，也就是当前这个值是什么，你是完全知道的。至于不保证原子性，就很明显了，这个值谁都可以取来运算，从计算机角度来讲，跟普通变量的区别就在于：效率差了。因为写入和读取高速缓存，效率远远高于内存。一路题外话，不要以为数据库插入数据就直接到磁盘了，其实写入的也是缓存，由后台线程刷到磁盘的。这样既可以起到缓冲的作用，又可以提高效率。不然你以为怎么能那么快。其实，从底层到高层，从硬件到软件，很多原理都是相通的。
————————————
感谢朋友们的认可和指正。本文是有感而发，因为看过了太多坑人的博客和书籍，感慨自己走过的弯路，不希望其他初学者被网上互相抄袭的博客和东拼西凑的书籍浪费时间，想以一个相对宏观的视野来描述一个概念，力求通俗易懂，所以没有深入太多细节，简化了很多模型，给部分朋友造成了疑惑，说声抱歉。也没有配图，都是抽时间手机码字，打个分割线都费劲，图呢，其实网上都有。
记得我在另外一篇答案中提到，计算机程序（不仅仅各种语言的代码，一切能向计算机发出指令的序列都是程序，当然包括Java虚拟机）的努力方向：最大化利用计算机资源。多线程就是如此，一个CPU密集型的任务在跑，你让IO干等着，这不是浪费吗？所以，这时候你启动一个IO密集型的任务，资源利用率就提升了。当然，这是一种简化模型，实际上一个人任务的不同阶段，需要的计算机资源是不同的，如果你能合理安排多个任务的执行逻辑，资源利用率就会很大提升。
我们学习程序语言，一定不要被束缚到语言细节和规范上去，而要从计算机逻辑执行层面思考问题。因为细节和规范都是人为设定的，是大牛抽象计算机逻辑后的加工品，你囿于此，其实是在理解别人的思想，而不是理解计算机。我们常说的高层依赖于抽象而不依赖于底层，是一样的意思。说了这么多，想表达的就是，对技术问题，要有思考的深度，要寻根溯源，要高屋建瓴。
回到多线程。上面提到synchronized，必须多说几句，这对理解锁的本质至关重要。多线程和锁，首先请大家记住一个场景：多人上厕所。
多线程和锁，一个是线程，一个是对象。一个在私有的线程栈中，一个在共享的堆中。如何标识某个线程持有某个锁对象？如何如何标志某个对象被某个线程锁定？很显然，线程栈中开启一片区域“栈帧”存储对象锁记录，堆中对象有对象头(对象头主要保存了对象的类元数据，以及对象的运行时状态，其中就包括了锁线程和GC分代等信息。)可以标识被哪个线程锁定。实际上，虚拟机就是利用对象头和monitor(后面讲)来实现锁的。
回到多人上厕所，人比做线程，厕所比做共享对象，锁比做对象头，monitor比做钥匙。
synchronized锁的是一个对象，或者是类的某个实例，或者是类本身（即常量池的Class）。 synchronized内部原理是通过对象内部的一个叫做监视器（monitor）来实现的。本质又是依赖于底层的操作系统的Mutex Lock来实现的。而操作系统实现线程之间的切换需要从用户态转换到核心态，这个成本非常高，这就是为什么synchronized效率低的原因。比如Hashtable(再次吐槽小写t，浑身难受)和用Collections.synchronizedMap装饰的HashMap，内部都使用了 synchronized，所以性能差，不是因为“它性能差”，而是因为“它使用的同步方式”性能差，那天人家底层重写了性能高了你怎么办？很多时候，点下鼠标进入源码看几眼就知道的东西，没必要死记硬背。
synchronized这种依赖于操作系统所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。别被这些名词砸晕了，这些锁的名字很有误导性，其实是对获取锁的方式的优化，不是锁。
所谓锁的优化，主要方向是优化获取锁的方式和加锁(释放)的方式。我不想一一解释枯燥名词。还是用上厕所举例。重量级锁可以认为是，你去上厕所，得先去管理处(人或者机器)登记并拿到钥匙上厕所，这个过程可以认为存在一次“用户态”到“内核态”的切换。是非常重量级的。
这里我必须强调一下，你的目标是上厕所，不是加锁，加锁只是为了你更好的上厕所。线程也一样，目的是为了完成某项任务。加锁是不得以为之的。
假如一层楼就你一个人，一个厕所， 你觉得还有必要去登记吗？要什么自行车？直接上啊。这就是无锁状态；如果这层楼还有一个哥们，但他尿泡比较强悍，一天不上厕所。厕所门上有个显示器，能显示上次上厕所的是谁、期间有没有其他人上厕所，那你上的时候，只要看下显示器就知道：没别人上过，还是我，照片都没变，不用刷脸，此厕可直接上。这就是偏向锁，因为“偏向你”；假如这个哥们偶尔也上一次，这次你发现厕所有别人上过，因为显示器上有他照片，那你就得重新刷脸，好吧，那我再刷了上吧，大部分时候，里面都没这哥们，你可顺利上厕所，这叫轻量级锁；如果某天这哥们腹泻(我一同事吃湖南蒸菜有过一次)，那你悲剧了，你每次上的时候，不仅显示器不是你，你想刷脸进入，发展里面还有人。没办法，只能去管理处登记等待了，变成了重量级锁。锁升级是不会降级的。这里，重量级锁涉及操作系统的处理，而偏向锁和轻量级锁涉及CAS，硬件可以搞定，效率更高。
上述锁状态转移和加锁(解锁不讲了)是由虚拟机(配合操作系统)完成的，我们不可见，既然是虚拟机控制，当然就有相关参数，如是否启用偏向锁，我忘了参数名字，但我知道肯定有这样的参数。如果面试我的面试官因为我不知道参数名字鄙视我，我能反怼死他。记个别人定的名字很自豪？
上面讲到重量级锁的时候，其实就是锁竞争很激烈的时候。比如早上高峰期，厕所坑位紧缺，排队的人很多，如果你一直等，等待的状态就叫“自旋”，当然你可以自旋十分钟左右后离开(虚拟机自旋也有参数控制)，因为你觉得里面的哥们玩手机不知道啥时候结束，你有更重要的事情要干，还不如去外面登记等通知。显然，自旋的前提是你知道上一个哥们不会很久。多次之后，你会摸清这些人上厕所的时间后，你自旋起来就更有针对性了，这叫“适应性自旋”。
还有，锁消除，锁粗化，比如基本没人用的StringBuffer、Vector，你用在某个方法中，其实根本没必要加锁，或者说比如连续的append，没必要每次都加锁，虚拟机就会进行锁消除或者锁粗化处理。
上面讲了这么多，主体是线程和锁对象，核心是获取锁的方式和锁定的方式，还有，不加锁或者“伪加锁”是不是能搞定？再次强调一遍，线程生来是为了完成任务的，不是为了和锁纠缠的。
多线程竞争锁的时候，肯定涉及到线程的排队，新来的线程怎么处理，是去竞争锁还是直接排队？排队中的线程，那些有资格竞争锁？有资格的线程，那个拿到锁(只是拿到锁，还未执行共享区)？不管怎么实现，这些东西是必须要考虑的。你在synchronized没见到，是因为虚拟机帮你处理了，涉及的队列也是虚拟机在维护。重量级锁的时候，又涉及和操作系统信号的交互。当然，要是你不用和操作系统进行如Mutex Lock这样“重量级的”交互也能更好、更快、更好的处理同步，那你就是大牛了。
大牛当然是存在，比如李老头。下面会开始讲更加灵活的、细粒度、可定制的Lock锁。可以认为是把synchronized加锁的过程、锁定的方式等流程中细节拆分出来，用灵巧的实现方式实现线程同步。再后面会讲对象的wait、notify，线程的sleep，主体不一样，思考的角度不一样。今天先到这里
扫一扫
920
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
