Java知识点总结

1、在Java中如何使用execute()、executeQuery()、executeUpdate()三个方法？
execute(String sql)

      执行给定的 SQL 语句，该语句可能返回多个结果。

executeQuery(String sql)

      执行给定的 SQL 语句，该语句返回单个 ResultSet 对象

executeUpdate(String sql)

      执行给定 SQL 语句，该语句可能为 INSERT、UPDATE 或 DELETE 语句，或者不返回任何内容的 SQL 语句（如 SQL DDL 语句）

头2种一般在查询中使用

最后一个在插入、更新、删除时使用

2、executeQuery()是干什么用的?实现什么功能啊？
使用JDBC连接数据库需要四步，第一步加载驱动程序；第二步，连接数据库；第三步，访问数据库；第四步，执行查询；其中在第四步执行查询时，要用statement类的executeQuery()方法来下达select指令以查询数据库，executeQuery()方法会把数据库响应的查询结果存放在ResultSet类对象中供我们使用。即语句：String sql="select * from"+tableName; ResultSet rs=s.executeQuery(sql);

3、executeQuery、executeUpdate或execute方法区别？
在用纯JSP做一个页面报警功能的时候习惯性的用executeQuery来执行SQL语句，结果执行update时就遇到问题，语句能执行，但返回结果出现问题，另外还忽略了executeUpdate的返回值不是结果集ResultSet,而是数值！特收藏如下一篇文章（感谢网友们对各种信息的贡献）：

JDBCTM中Statement接口提供的execute、executeQuery和executeUpdate之间的区别

Statement 接口提供了三种执行 SQL 语句的方法：executeQuery、executeUpdate 和 execute。使用哪一个方法由 SQL 语句所产生的内容决定。

方法executeQuery
用于产生单个结果集的语句，例如 SELECT 语句。 被使用最多的执行 SQL 语句的方法是 executeQuery。这个方法被用来执行 SELECT 语句，它几乎是使用最多的 SQL 语句。

方法executeUpdate
用于执行 INSERT、UPDATE 或 DELETE 语句以及 SQL DDL（数据定义语言）语句，例如 CREATE TABLE 和 DROP TABLE。INSERT、UPDATE 或 DELETE 语句的效果是修改表中零行或多行中的一列或多列。executeUpdate 的返回值是一个整数，指示受影响的行数（即更新计数）。对于 CREATE TABLE 或 DROP TABLE 等不操作行的语句，executeUpdate 的返回值总为零。

使用executeUpdate方法是因为在 createTableCoffees 中的 SQL 语句是 DDL （数据定义语言）语句。创建表，改变表，删除表都是 DDL 语句的例子，要用 executeUpdate 方法来执行。你也可以从它的名字里看出，方法 executeUpdate 也被用于执行更新表 SQL 语句。实际上，相对于创建表来说，executeUpdate 用于更新表的时间更多，因为表只需要创建一次，但经常被更新。

方法execute：
用于执行返回多个结果集、多个更新计数或二者组合的语句。因为多数程序员不会需要该高级功能

execute方法应该仅在语句能返回多个ResultSet对象、多个更新计数或ResultSet对象与更新计数的组合时使用。当执行某个已存储过程 或动态执行未知 SQL 字符串（即应用程序程序员在编译时未知）时，有可能出现多个结果的情况，尽管这种情况很少见。
因为方法 execute 处理非常规情况，所以获取其结果需要一些特殊处理并不足为怪。例如，假定已知某个过程返回两个结果集，则在使用方法 execute 执行该过程后，必须调用方法 getResultSet 获得第一个结果集，然后调用适当的 getXXX 方法获取其中的值。要获得第二个结果集，需要先调用 getMoreResults 方法，然后再调用 getResultSet 方法。如果已知某个过程返回两个更新计数，则首先调用方法 getUpdateCount，然后调用 getMoreResults，并再次调用 getUpdateCount。
对于不知道返回内容，则情况更为复杂。如果结果是 ResultSet 对象，则方法 execute 返回 true；如果结果是 Java int，则返回 false。如果返回 int，则意味着结果是更新计数或执行的语句是 DDL 命令。在调用方法 execute 之后要做的第一件事情是调用 getResultSet 或 getUpdateCount。调用方法 getResultSet 可以获得两个或多个 ResultSet 对象中第一个对象；或调用方法 getUpdateCount 可以获得两个或多个更新计数中第一个更新计数的内容。
当 SQL 语句的结果不是结果集时，则方法 getResultSet 将返回 null。这可能意味着结果是一个更新计数或没有其它结果。在这种情况下，判断 null 真正含义的唯一方法是调用方法 getUpdateCount，它将返回一个整数。这个整数为调用语句所影响的行数；如果为 -1 则表示结果是结果集或没有结果。如果方法 getResultSet 已返回 null（表示结果不是 ResultSet 对象），则返回值 -1 表示没有其它结果。也就是说，当下列条件为真时表示没有结果（或没有其它结果）：

((stmt.getResultSet() == null) && (stmt.getUpdateCount() == -1))

如果已经调用方法 getResultSet 并处理了它返回的 ResultSet 对象，则有必要调用方法 getMoreResults 以确定是否有其它结果集或更新计数。如果 getMoreResults 返回 true，则需要再次调用 getResultSet 来检索下一个结果集。如上所述，如果 getResultSet 返回 null，则需要调用 getUpdateCount 来检查 null 是表示结果为更新计数还是表示没有其它结果。

当 getMoreResults 返回 false 时，它表示该 SQL 语句返回一个更新计数或没有其它结果。因此需要调用方法 getUpdateCount 来检查它是哪一种情况。在这种情况下，当下列条件为真时表示没有其它结果：

((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))

下面的代码演示了一种方法用来确认已访问调用方法 execute 所产生的全部结果集和更新计数：

stmt.execute(queryStringWithUnknownResults);
while (true) {
int rowCount = stmt.getUpdateCount();
if (rowCount > 0) { // 它是更新计数
System.out.println("Rows changed = " + count);
stmt.getMoreResults();

　　在传统的Java应用中，Bean的生命周期非常简单。Java的关键词new用来实例化Bean（或许他是非序列化的）。这样就够用了。相反，Bean 的生命周期在spring容器中更加细致。理解Spring Bean的生命周期非常重要，因为你或许要利用Spring提供的机会来订制Bean的创建过程。

1.容器寻找Bean的定义信息并且将其实例化。

2.使用依赖注入，Spring按照Bean定义信息配置Bean的所有属性。

3.如果Bean实现了BeanNameAware接口，工厂调用Bean的setBeanName()方法传递Bean的ID。

4.如果Bean实现了BeanFactoryAware接口，工厂调用setBeanFactory()方法传入工厂自身。

5.如果BeanPostProcessor和Bean关联，那么它们的postProcessBeforeInitialzation()方法将被调用。

6.如果Bean指定了init-method方法，它将被调用。

7.最后，如果有BeanPsotProcessor和Bean关联，那么它们的postProcessAfterInitialization()方法将被调用。

　　到这个时候，Bean已经可以被应用系统使用了，并且将被保留在Bean Factory中知道它不再需要。有两种方法可以把它从Bean Factory中删除掉。

1.如果Bean实现了DisposableBean接口，destory()方法被调用。

2.如果指定了订制的销毁方法，就调用这个方法。

　　Bean在Spring应用上下文的生命周期与在Bean工厂中的生命周期只有一点不同，唯一不同的是，如果Bean实现了ApplicationContextAwre接口，setApplicationContext()方法被调用。

　　MySQL Hash索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。
　　可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。
（1）MySQL Hash索引仅仅能满足"=","IN"和"< >"查询，不能使用范围查询。
由于 MySQL Hash索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。
（2）MySQL Hash索引无法被用来避免数据的排序操作。
由于 MySQL Hash索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；
（3）MySQL Hash索引不能利用部分索引键查询。
对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是多带带计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
（4）MySQL Hash索引在任何时候都不能避免表扫描。
前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
（5）MySQL Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。
对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。

单例的特点：

1、保证某类只存在唯一实例。
2、该类本身完成自身的初始化。
3、获取该唯一实例的方式非常明确，可以通过该类本身定义的静态方法getInstance()获取该类的唯一实例引用。

静态变量定义某类的实例引用特点：
1、该类的实例引用的静态变量可定义在任何文档类当中。
2、获取该类的实例引用的静态变量，可以通过定义该静态变量的类名通过点语法进行访问该引用。
3、任何位置可以对该静态变量进行重新赋值。

　　通过这两者方式的特点，我们可以很明显的看出两者之间的区别。（这一切都是基于某类只需要存在一个实例对象的前提来讨论）
首先静态变量方式不能确保某类的实例的唯一性，这样在项目中，可能因为在某个文档类中对该静态变量进行再次赋值，存不可意料的风险（这种风险可以规避）。同样的，因为静态变量的定义的位置不确定，所以需要协议商定，这些静态变量分类别进行定义在一个固定的位置（比如说某个专门存放静态变量方式的某类的对象的引用的文档类当中）。
　　而单例模式也就是静态变量方式创建一个类的实例引用所带来的缺陷的改善。首先解决引用的唯一实例可能被重新赋值的问题，单例模式中的getInstance()静态方法实现时，采用懒汉式创建一个对象（当然这只是创建方式的一种），规避了这一风险，无则创建，有则跳过创建。其次，getInstance()静态方法定义在该类的内部，获取该类对象的引用位置非常明确，无需额外的沟通商定，团队成员拿起即用。最后一个区别并不是很明显，声明一个静态变量，实际上，我们会直接对其进行初始化赋值，这样，在内存占用上，所占用的内存为该初始化赋值对象实际的内存。而单例模式可以通过懒汉创建法延迟该内存的占用，要知道，当一个静态变量只进行声明，而不进行初始化时，实际的内存占用只有4个字节（笔者个人推测，这四个字节只是一个指针地址所占用的内存空间）。

HashMap/HashTable初始容量大小和每次扩充容量大小的不同

可以看到HashTable默认的初始大小为11，之后每次扩充为原来的2n+1。HashMap默认的初始化大小为16，之后每次扩充为原来的2倍。还有我没列出代码的一点，就是如果在创建时给定了初始化大小，那么HashTable会直接使用你给定的大小，而HashMap会将其扩充为2的幂次方大小。

也就是说HashTable会尽量使用素数、奇数。而HashMap则总是使用2的幂作为哈希表的大小。我们知道当哈希表的大小为素数时，简单的取模哈希的结果会更加均匀（具体证明，见这篇文章），所以单从这一点上看，HashTable的哈希表大小选择，似乎更高明些。但另一方面我们又知道，在取模计算时，如果模数是2的幂，那么我们可以直接使用位运算来得到结果，效率要大大高于做除法。所以从hash计算的效率上，又是HashMap更胜一筹。

所以，事实就是HashMap为了加快hash的速度，将哈希表的大小固定为了2的幂。当然这引入了哈希分布不均匀的问题，所以HashMap为解决这问题，又对hash算法做了一些改动。具体我们来看看，在获取了key对象的hashCode之后，HashTable和HashMap分别是怎样将他们hash到确定的哈希桶（Entry数组位置）中的。

正如我们所言，HashMap由于使用了2的幂次方，所以在取模运算时不需要做除法，只需要位的与运算就可以了。但是由于引入的hash冲突加剧问题，HashMap在调用了对象的hashCode方法之后，又做了一些位运算在打散数据。关于这些位计算为什么可以打散数据的问题，本文不再展开了。感兴趣的可以看这里。

HashMap是支持null键和null值的，而HashTable在遇到null时，会抛出NullPointerException异常。

这并不是因为HashTable有什么特殊的实现层面的原因导致不能支持null键和null值，这仅仅是因为HashMap在实现时对null做了特殊处理，将null的hashCode值定为了0，从而将其存放在哈希表的第0个bucket中。

1：先将top.jsp中的java脚本和jsp指令都执行完毕以后再将top.jsp页面加入到引用页面中。

2：<%@ include file="top.jsp"%>静态读取：则是将top.jsp的整个页面不加解析（无论是脚本还是指令）统统读入到引用页面中，然后和引用页面一起进行解析（即开始执行脚本和指令）。

3：区别：其实上边的两条就是区别，但是需要注意的是用<%@ include file=""%>的时候被引用页面中不能再出现其他网页标签和page指令了，否则会冲突的

（jsp:include page=""）

父页面和包含进来的页面多带带编译，多带带翻译成servlet后，在前台拼成一个HTML页面。

（%@include file=""%）

父页面和包含进来的页面，代码合并后，才一起翻译成servlet，反馈到前台，形成一个HTML页面。

由此我们知道：jsp页面是把include指令元素（<%@ include file=""%>）所指定的页面的实际内容（也就是代码段）加入到引入它的jsp页面中,合成一个文件后被jsp容器将它转化成servlet。可以看到这时会产生一个临时class文件和一个servlet源文件。而动作元素（）是在请求处理阶段引入的，会被JSP容器生成两个临时class文件和两个servlet原文件。而引入的只是servlet的输出结果，即JspWriter对象的输出结果，而不是jsp的源代码。

java是在服务器端运行的代码，jsp在服务器的servlet里运行，而javascript和html都是在浏览器端运行的代码。所以加载执行顺序是是java>jsp>js。

所有的JSP都会在客户端发出请求后被容器转译成servlet的源代码（java），然后再将源码（java）编译成servlet的类（class），放入到内存里面。

1.可重入锁

如果锁具备可重入性，则称作为可重入锁。

像Synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：

基于线程的分配，而不是基于方法调用的分配。

举个简单的例子，当一个线程执行到某个Synchronized方法时，比如说method1，而在method1中会调用另外一个Synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

class MyClass {
    public synchronized void method1() {
        method2();
    }
     
    public synchronized void method2() {
         
    }
}

上述代码中的两个方法method1和method2都用Synchronized修饰了。

假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是Synchronized方法，假如Synchronized不具备可重入性，此时线程A需要重新申请锁。

但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。

而由于Synchronized和Lock都具备可重入性，所以不会发生上述现象。

2.可中断锁

可中断锁：顾名思义，就是可以响应中断的锁。

在Java中，Synchronized就不是可中断锁，而Lock是可中断锁。

如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。

在前面演示LockInterruptibly()的用法时已经体现了Lock的可中断性。

3.公平锁

公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。

非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。

在Java中，Synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。

而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。这一点由构造函数可知：

public ReentrantLock() {
        sync = new NonfairSync();
    }


    public ReentrantLock(boolean fair) {
        sync = (fair)? new FairSync() : new NonfairSync();
    }

在ReentrantLock中定义了2个静态内部类，一个是NotFairSync，一个是FairSync，分别用来实现非公平锁和公平锁。

我们可以在创建ReentrantLock对象时，通过知道布尔参数来决定使用非公平锁还是公平锁。

如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。

另外在ReentrantLock类中定义了很多方法，比如：

isFair()        //判断锁是否是公平锁
isLocked()    //判断锁是否被任何线程获取了
isHeldByCurrentThread()   //判断锁是否被当前线程获取了 
hasQueuedThreads()   //判断是否有线程在等待该锁

在ReentrantReadWriteLock中也有类似的方法，同样也可以设置为公平锁和非公平锁。

不过要记住，ReentrantReadWriteLock并未实现Lock接口，它实现的是ReadWriteLock接口。

4.读写锁

读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。

正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。

ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。

可以通过readLock()获取读锁，通过writeLock()获取写锁。

乐观锁是假定读取的数据，在写之前不会被更新。适用于数据更新不频繁的场景。

相反，当数据更新频繁的时候，乐观锁的效率很低，因为基本上每次写的时候都要重复读写两次以上。

对于数据更新频繁的场合，悲观锁效率更高 ；

对于数据更新不频繁的场合，乐观锁效率更高；

一般来说如果并发量很高的话，建议使用悲观锁，否则的话就使用乐观锁。

如果并发量很高时使用乐观锁的话，会导致很多的并发事务回滚、操作失败。

线程工作内存是cpu寄存器和高速缓存的抽象描述，使用频率高的数据从主存拷贝到高速缓存中，每个线程在cpu高速缓存中对拷贝的数据进行读取、计算、赋值，再在合适的时候同步更新到主存的该数据，如i=1，i+1=2，若2在更新到主存前，其他线程是不知道该值被改变了，其他线程高速缓存中该值依然为1。

解决方法：需要各线程间可见的变量前加上volatile修饰，在一个线程的高速缓存中改变该值时，其他线程会获得该值的更新值。

垃圾收集器：

串行：Serial、Parallel、CMS

CMS:每个垃圾收集周期只有两次短的停顿，开始时有一个短的停顿，称为初始标记；标记从外部直接可达的老年代对象；然后在并发标记阶段，标记所有从这些对象可达的存活对象；由于在标记期间应用可能正在运行并更新引用，所以到并发标记阶段结束时，未必所有存活的对象都能确保被标记；所以必须再次停顿，称为重新标记；最后一个阶段是并发清除。

dbcp没有自动地去回收空闲连接的功能 c3p0有自动回收空闲连接功能 。

两者主要是对数据连接的处理方式不同！c3p0提供最大空闲时间，dbcp提供最大连接数。

前者当连接超过最大空闲连接时间时，当前连接就会被断掉。dbcp当连接数超过最大连接数时，所有连接都会被断开。

dbcp和c3p0都是单线程的，在高并发的环境下性能会非常低下；tomcat jdbc pool 近乎兼容 dbcp ，性能更高，异步方式获取连接。