企业面试遇到的问题02
1、你们在数据库上有没有使用垂直分库和水平分库以及读写分离。说说你的理解以及使用场景
- 垂直分库
按列进行分割，即把一条记录分开多个地方保存，每个子表的行数相同。
把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O 次数。其缺点是需要管理冗余列，查询所有数据需要join操作。
例如有表T1
id name qty
--------------
1 p1 10
2 p2 20
3 p3 30
4 p4 40
......
......
- 水平分库
按记录进分分割，不同的记录可以分开保存，每个子表的列数相同。
水平分割通常在下面的情况下使用，应用场景：
A 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。
B 表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。
C需要把数据存放到多个介质上。
例如法规表law就可以分成两个表active－law和 inactive－law。active－law表中的内容是正生效的法规，是经常使用的，而inactive－law表则使已经作废的法规，不常被查询。水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。
- 总结：
垂直分割就是按列进行分割，即把一条记录分开多个地方保存，每个子表的行数相同。
例如表T1，可以把id和name放到数据文件p1，把qty放到数据文件p2。
水平分割就是按记录进分分割，不同的记录可以分开保存，每个子表的列数相同。
像表T1，可以把id为单数的放到数据文件P1，双数的放到数据文件P2。
- 读写分离
数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。
对于大访问量的网站，一般会采用读写分离，比如ebay的读写比率是260：1，也就是大型的电子商务网站的。
网上看到说采用读写分离有如下工具：
1，oracle的logical standby
2, Quest公司的SharePlex
3, DSG公司的RealSyncMySQLReplication可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。MySQL
Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQLProxy是完全透明的，应用则只需要连接到MySQLProxy的监听端口即可。
2、请谈谈垂直分库和水平分库以及读写分离会遇到的问题，并提出可行的解决方案
垂直分库：按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。
需要解决的问题：跨数据库的事务、jion查询等问题？【需要提供解决方案】
水平分库：按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。
需要解决的问题：数据路由、组装？【需要提供解决方案】
读写分离：对于时效性不高的数据，可以通过读写分离缓解数据库压力。
需要解决的问题：在业务上区分哪些业务上是允许一定时间延迟的，以及数据同步问题？【需要提供解决方案】
3、请结合实际应用具体讲解一下单点登录
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
中文名
单点登录
外文名
Single Sign On
简 称
SSO
解 释
企业业务整合的解决方案
目录
1企业应用集成
2技术实现机制
3实现应用优势
▪ 技术实现
▪ 应用优势
- 1企业应用集成
通常情况下运维内控审计系统、4A系统都包含此项功能，目的是简化账号登录过程并保护账号和密码安全，对账号进行统一管理。
企业应用集成（EAI, Enterprise Application Integration）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还有一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。
在信息安全管理中，访问控制(Access Controls)环绕四个过程：Identification；Authentication；Authorization；Accountability。单点登录（Single Sign On）属于Authorization授权系统，除单点登录外还包括：Lightweight Directory Access Protocol 和 Authorization ticket。（Michael E. Whitman (2011) Management Of Information Security Kennesaw University)
- 2技术实现机制
当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
- 3实现应用优势
技术实现
以金万维单点登录为例：
如图所示：统一的身份认证系统主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行校验，判断其有效性。整个系统可以存在两个以上的认证服务器，这些服务器甚至可以是不同的产品。认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。
- 应用优势
单点登录：用户只需登录一次，即可通过单点登录系统（eTrueSSO）访问后台的多个 应用系统，二次登录时无需重新输入用户名和密码
4、商品上架怎么审核？具体的审核步骤？是否需要专门的人员做审批？（电商项目老师提供）
1、首先学生遇到这种问题可以先反问贵公司是否有上架审核这一岗位职责或者前期业务规划的时候有这一功能，根据这一问题的答案做后续的回答；
2、一般公司前期业务规划的时候，是考虑过上架审核的，因为担心会有非法商品或者非法信息出现。但是后期真实运营之后就去掉了该功能。原因如下：
a)、该部分工作是特别繁重而且没有技术含量的，特别是商城刚上线之初，大量的sku上架发布，这个工作量就会非常大，导致人员成本升高。
b)、可以通过业务约束规避该问题，没必要再设立一个岗位去审核它。如果是B2C，则内部发布商品的运营人员通过岗位培训，必须要知道哪些商品是非法的，哪些信息是非法的，发布商品时需要注意（即发布时也有审核的概念）。如果是B2B2C，则在和商家签订合同时就要有这方面的约束，如果商城发现该商家有非法商品或显示有非法信息，则客服人员可以通过强制下架功能对其制裁（该商品无法再次上架，相当于删除掉了），并从该商家的保证金中扣除相关罚款。
c)、即使不考虑上面的原因，那么想设定一个上架审核岗位，怎么设定？管理层的人，没时间去审核。普通员工，做审核功能也有点欠妥。
3、当然有些项目可能用户必须要求去做上架审核，那么可以提供批量审核功能，同时要记录审核日志，其中包括审核人、审核意见。
商品上架可以参考以下图去说：
5、JVM虚拟机有内存泄露怎么解决
- java内存管理机制
在C++ 语言中，如果需要动态分配一块内存，程序员需要负责这块内存的整个生命周期。从申请分配、到使用、再到最后的释放。这样的过程非常灵活，但是却十分繁琐，程序员很容易由于疏忽而忘记释放内存，从而导致内存的泄露。 Java 语言对内存管理做了自己的优化，这就是垃圾回收机制。 Java 的几乎所有内存对象都是在堆内存上分配（基本数据类型除外），然后由 GC （ garbage collection）负责自动回收不再使用的内存。
上面是Java 内存管理机制的基本情况。但是如果仅仅理解到这里，我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑，既然 Java 的垃圾回收机制能够自动的回收内存，怎么还会出现内存泄漏的情况呢？这个问题，我们需要知道 GC 在什么时候回收内存对象，什么样的内存对象会被 GC 认为是“不再使用”的。
Java中对内存对象的访问，使用的是引用的方式。在 Java 代码中我们维护一个内存对象的引用变量，通过这个引用变量的值，我们可以访问到对应的内存地址中的内存对象空间。在 Java 程序中，这个引用变量本身既可以存放堆内存中，又可以放在代码栈的内存中（与基本数据类型相同）。 GC 线程会从代码栈中的引用变量开始跟踪，从而判定哪些内存是正在使用的。如果 GC 线程通过这种方式，无法跟踪到某一块堆内存，那么 GC 就认为这块内存将不再使用了（因为代码中已经无法访问这块内存了）。
通过这种有向图的内存管理方式，当一个内存对象失去了所有的引用之后，GC 就可以将其回收。反过来说，如果这个对象还存在引用，那么它将不会被 GC 回收，哪怕是 Java 虚拟机抛出 OutOfMemoryError 。
- Java内存泄露
一般来说内存泄漏有两种情况。
一种情况如在C/C++ 语言中的，在堆中的分配的内存，在没有将其释放掉的时候，就将所有能访问这块内存的方式都删掉（如指针重新赋值）；
另一种情况则是在内存对象明明已经不需要的时候，还仍然保留着这块内存和它的访问方式（引用）。
第一种情况，在 Java 中已经由于垃圾回收机制的引入，得到了很好的解决。所以， Java 中的内存泄漏，主要指的是第二种情况。
可能光说概念太抽象了，大家可以看一下这样的例子：
Vector v = new Vector( 10 );
for ( int i = 1 ;i < 100 ; i ++ ){
Object o = new Object();
v.add(o);
o = null ;
}
在这个例子中，代码栈中存在Vector 对象的引用 v 和 Object 对象的引用 o 。在 For 循环中，我们不断的生成新的对象，然后将其添加到 Vector 对象中，之后将 o 引用置空。问题是当 o 引用被置空后，如果发生 GC，我们创建的 Object 对象是否能够被 GC 回收呢？答案是否定的。因为， GC 在跟踪代码栈中的引用时，会发现 v 引用，而继续往下跟踪，就会发现 v 引用指向的内存空间中又存在指向 Object 对象的引用。也就是说尽管o 引用已经被置空，但是 Object 对象仍然存在其他的引用，是可以被访问到的，所以 GC 无法将其释放掉。如果在此循环之后， Object 对象对程序已经没有任何作用，那么我们就认为此 Java 程序发生了内存泄漏。
尽管对于C/C++ 中的内存泄露情况来说， Java 内存泄露导致的破坏性小，除了少数情况会出现程序崩溃的情况外，大多数情况下程序仍然能正常运行。但是，在移动设备对于内存和 CPU 都有较严格的限制的情况下，Java 的内存溢出会导致程序效率低下、占用大量不需要的内存等问题。这将导致整个机器性能变差，严重的也会引起抛出 OutOfMemoryError ，导致程序崩溃。
- 一般情况下内存泄漏的避免
在不涉及复杂数据结构的一般情况下，Java 的内存泄露表现为一个内存对象的生命周期超出了程序需要它的时间长度。我们有时也将其称为“对象游离”。
例如：
public class FileSearch{
private byte [] content;
private File mFile;
public FileSearch(File file){
mFile = file;
}
public boolean hasString(String str){
int size = getFileSize(mFile);
content = new byte [size];
loadFile(mFile, content);
String s = new String(content);
return s.contains(str);
}
}
在这段代码中，FileSearch 类中有一个函数 hasString ，用来判断文档中是否含有指定的字符串。流程是先将mFile 加载到内存中，然后进行判断。但是，这里的问题是，将 content 声明为了实例变量，而不是本地变量。于是，在此函数返回之后，内存中仍然存在整个文件的数据。而很明显，这些数据我们后续是不再需要的，这就造成了内存的无故浪费。
要避免这种情况下的内存泄露，要求我们以C/C++ 的内存管理思维来管理自己分配的内存。第一，是在声明对象引用之前，明确内存对象的有效作用域。在一个函数内有效的内存对象，应该声明为 local 变量，与类实例生命周期相同的要声明为实例变量……以此类推。第二，在内存对象不再需要时，记得手动将其引用置空。
复杂数据结构中的内存泄露问题
在 实际的项目中，我们经常用到一些较为复杂的数据结构用于缓存程序运行过程中需要的数据信息。有时，由于数据结构过于复杂，或者我们存在一些特殊的需求（例 如，在内存允许的情况下，尽可能多的缓存信息来提高程序的运行速度等情况），我们很难对数据结构中数据的生命周期作出明确的界定。这个时候，我们可以使用Java 中一种特殊的机制来达到防止内存泄露的目的。
之前我们介绍过，Java 的 GC 机制是建立在跟踪内存的引用机制上的。而在此之前，我们所使用的引用都只是定义一个“ Object o; ”这样形式的。事实上，这只是 Java 引用机制中的一种默认情况，除此之外，还有其他的一些引用方式。通过使用这些特殊的引用机制，配合 GC 机制，就可以达到一些我们需要的效果。
Java中的几种引用方式
Java中有几种不同的引用方式，它们分别是：强引用、软引用、弱引用和虚引用。下面，我们首先详细地了解下这几种引用方式的意义。
强引用
在此之前我们介绍的内容中所使用的引用 都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空 间不足，Java 虚拟机宁愿抛出OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
软引用（SoftReference ）
SoftReference 类的一个典型用途就是用于内存敏感的高速缓存。 SoftReference 的原理是：在保持对对象的引用时保证在 JVM 报告内存不足情况之前将清除所有的软引用。关键之处在于，垃圾收集器在运行时可能会（也可能不会）释放软可及对象。对象是否被释放取决于垃圾收集器的算法 以及垃圾收集器运行时可用的内存数量。
弱引用（WeakReference ）
WeakReference 类的一个典型用途就是规范化映射（ canonicalized mapping ）。另外，对于那些生存期相对较长而且重新创建的开销也不高的对象来说，弱引用也比较有用。关键之处在于，垃圾收集器运行时如果碰到了弱可及对象，将释放 WeakReference 引用的对象。然而，请注意，垃圾收集器可能要运行多次才能找到并释放弱可及对象。
虚引用（PhantomReference ）
PhantomReference 类只能用于跟踪对被引用对象即将进行的收集。同样，它还能用于执行 pre-mortem 清除操作。PhantomReference 必须与 ReferenceQueue 类一起使用。需要 ReferenceQueue 是因为它能够充当通知机制。当垃圾收集器确定了某个对象是虚可及对象时， PhantomReference 对象就被放在它的 ReferenceQueue 上。将 PhantomReference 对象放在 ReferenceQueue 上也就是一个通知，表明 PhantomReference 对象引用的对象已经结束，可供收集了。这使您能够刚好在对象占用的内存被回收之前采取行动。 Reference与 ReferenceQueue 的配合使用。
GC、 Reference 与 ReferenceQueue 的交互
A、 GC无法删除存在强引用的对象的内存。
B、 GC发现一个只有软引用的对象内存，那么：
① SoftReference对象的 referent 域被设置为 null ，从而使该对象不再引用 heap 对象。
② SoftReference引用过的 heap 对象被声明为 finalizable 。
③ 当 heap 对象的 finalize() 方法被运行而且该对象占用的内存被释放， SoftReference 对象就被添加到它的 ReferenceQueue （如果后者存在的话）。
C、 GC发现一个只有弱引用的对象内存，那么：
① WeakReference对象的 referent 域被设置为 null , 从而使该对象不再引用heap 对象。
② WeakReference引用过的 heap 对象被声明为 finalizable 。
③ 当heap 对象的 finalize() 方法被运行而且该对象占用的内存被释放时， WeakReference 对象就被添加到它的ReferenceQueue （如果后者存在的话）。
D、 GC发现一个只有虚引用的对象内存，那么：
① PhantomReference引用过的 heap 对象被声明为 finalizable 。
② PhantomReference在堆对象被释放之前就被添加到它的 ReferenceQueue 。
值得注意的地方有以下几点：
1、 GC 在一般情况下不会发现软引用的内存对象，只有在内存明显不足的时候才会发现并释放软引用对象的内存。
2、 GC 对弱引用的发现和释放也不是立即的，有时需要重复几次 GC ，才会发现并释放弱引用的内存对象。
3、软引用和弱引用在添加到 ReferenceQueue 的时候，其指向真实内存的引用已经被置为空了，相关的内存也已经被释放掉了。而虚引用在添加到 ReferenceQueue 的时候，内存还没有释放，仍然可以对其进行访问。
代码示例
通过以上的介绍，相信您对Java 的引用机制以及几种引用方式的异同已经有了一定了解。光是概念，可能过于抽象，下面我们通过一个例子来演示如何在代码中使用 Reference 机制。
String str = new String( " hello " ); // ①
ReferenceQueue < String > rq = new ReferenceQueue < String > (); // ②
WeakReference < String > wf = new WeakReference < String > (str, rq); // ③
str = null ; // ④取消"hello"对象的强引用
String str1 = wf.get(); // ⑤假如"hello"对象没有被回收，str1引用"hello"对象
// 假如"hello"对象没有被回收，rq.poll()返回null
Reference ref = rq.poll(); // ⑥
在以上代码中，注意⑤⑥两处地方。假如“hello ”对象没有被回收 wf.get() 将返回“ hello ”字符串对象，rq.poll() 返回 null ；而加入“ hello ”对象已经被回收了，那么 wf.get() 返回 null ， rq.poll() 返回 Reference对象，但是此 Reference 对象中已经没有 str 对象的引用了 ( PhantomReference 则与WeakReference 、SoftReference 不同 )。
引用机制与复杂数据结构的联合应用
了解了GC 机制、引用机制，并配合上 ReferenceQueue ，我们就可以实现一些防止内存溢出的复杂数据类型。
例如，SoftReference 具有构建 Cache 系统的特质，因此我们可以结合哈希表实现一个简单的缓存系统。这样既能保证能够尽可能多的缓存信息，又可以保证 Java 虚拟机不会因为内存泄露而抛出 OutOfMemoryError 。这种缓存机制特别适合于内存对象生命周期长，且生成内存对象的耗时比较长的情况，例如缓存列表封面图片等。对于一些生命周期较长，但是生成内存对象开销不大的情况，使用WeakReference 能够达到更好的内存管理的效果。
附SoftHashmap 的源码一份，相信看过之后，大家会对 Reference 机制的应用有更深入的理解。
package com. *** .widget;
// : SoftHashMap.java
import java.util. * ;
import java.lang.ref. * ;
import android.util.Log;
public class SoftHashMap extends AbstractMap {
/** The internal HashMap that will hold the SoftReference. */
private final Map hash = new HashMap();
/** The number of "hard" references to hold internally. */
private final int HARD_SIZE;
/** The FIFO list of hard references, order of last access. */
private final LinkedList hardCache = new LinkedList();
/** Reference queue for cleared SoftReference objects. */
private ReferenceQueue queue = new ReferenceQueue();
// Strong Reference number
public SoftHashMap() { this ( 100 ); }
public SoftHashMap( int hardSize) { HARD_SIZE = hardSize; }
public Object get(Object key) {
Object result = null ;
// We get the SoftReference represented by that key
SoftReference soft_ref = (SoftReference)hash.get(key);
if (soft_ref != null ) {
// From the SoftReference we get the value, which can be
// null if it was not in the map, or it was removed in
// the processQueue() method defined below
result = soft_ref.get();
if (result == null ) {
// If the value has been garbage collected, remove the
// entry from the HashMap.
hash.remove(key);
} else {
// We now add this object to the beginning of the hard
// reference queue. One reference can occur more than
// once, because lookups of the FIFO queue are slow, so
// we don't want to search through it each time to remove
// duplicates.
// keep recent use object in memory
hardCache.addFirst(result);
if (hardCache.size() > HARD_SIZE) {
// Remove the last entry if list longer than HARD_SIZE
hardCache.removeLast();
}
}
}
return result;
}
/** We define our own subclass of SoftReference which contains
not only the value but also the key to make it easier to find
the entry in the HashMap after it's been garbage collected. */
private static class SoftValue extends SoftReference {
private final Object key; // always make data member final
/** Did you know that an outer class can access private data
members and methods of an inner class? I didn't know that!
I thought it was only the inner class who could access the
outer class's private information. An outer class can also
access private members of an inner class inside its inner
class. */
private SoftValue(Object k, Object key, ReferenceQueue q) {
super (k, q);
this .key = key;
}
}
/** Here we go through the ReferenceQueue and remove garbage
collected SoftValue objects from the HashMap by looking them
up using the SoftValue.key data member. */
public void processQueue() {
SoftValue sv;
while ((sv = (SoftValue)queue.poll()) != null ) {
if (sv.get() == null ) {
Log.e( " processQueue " , " null " );
} else {
Log.e( " processQueue " , " Not null " );
}
hash.remove(sv.key); // we can access private data!
Log.e( " SoftHashMap " , " release " + sv.key);
}
}
/** Here we put the key, value pair into the HashMap using
a SoftValue object. */
public Object put(Object key, Object value) {
processQueue(); // throw out garbage collected values first
Log.e( " SoftHashMap " , " put into " + key);
return hash.put(key, new SoftValue(value, key, queue));
}
public Object remove(Object key) {
processQueue(); // throw out garbage collected values first
return hash.remove(key);
}
public void clear() {
hardCache.clear();
processQueue(); // throw out garbage collected values
hash.clear();
}
public int size() {
processQueue(); // throw out garbage collected values first
return hash.size();
}
public Set entrySet() {
// no, no, you may NOT do that!!! GRRR
throw new UnsupportedOperationException();
}
}
6、JVM是否有深入了解、有什么优化、具体使用场景
一、Java内存回收机制
不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址。Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的。GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题。在Java语言中，判断一个内存空间是否符合垃圾收集标准有两个：一个是给对象赋予了空值null，以后再没有调用过，另一个是给对象赋予了新值，这样重新分配了内存空间。
二、Java内存泄露引起原因
首先，什么是内存泄露？经常听人谈起内存泄露，但要问什么是内存泄露，没几个说得清楚。内存泄露是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄露。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。
那么，Java内存泄露根本原因是什么呢？长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。具体主要有如下几大类：
1、静态集合类引起内存泄露：
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。
例:
代码如下:
Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}
在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。（解决方案）
2、当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。
例：
代码如下:
public static void main(String[] args)
{
Set set = new HashSet();
Person p1 = new Person("唐僧","pwd1",25);
Person p2 = new Person("孙悟空","pwd2",26);
Person p3 = new Person("猪八戒","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!
p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变
set.remove(p3); //此时remove不掉，造成内存泄漏
set.add(p3); //重新添加，居然添加成功
System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!
for (Person person : set)
{
System.out.println(person);
}
}
3、监听器
在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
4、各种连接
比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
5、内部类和外部模块等的引用
内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：
public void registerMsg(Object b);
这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。
6、单例模式
不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子：
代码如下:
class A{
public A(){
B.getInstance().setA(this);
}
....
}
B类采用单例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
显然B采用singleton模式，它持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较复杂的对象或者集合类型会发生什么情况
7、spring框架有哪些优化方案、有没有改过源代码？
要求学员把spring了解以下：参考：《详解Spring框架的设计理念与设计模式.doc》
可以回答，没有改过，spring框架封装的很完善了，覆盖了企业开发的大部分功能！
但是也可以回答：如果使用ssh开发，可以把spring提供的hibernateTemplate改改，支持多种查询！即修改hibernateTemplate操作的API
8、hibernate、mybatis框架有哪些优化方案
比较：
Hibernate和Mybatis都是orm对象关系映射框架，都是用于将数据持久化的框架技术。
Hiberante较深度的封装了jdbc，对开发者写sql的能力要求的不是那么的高，我们只要通过hql语句操作对象即可完成对数据持久化的操作了。
另外hibernate可移植性好，如一个项目开始使用的是mysql数据库，但是随着业务的发展，现mysql数据库已经无法满足当前的绣球了，现在决定使用Oracle数据库，虽然sql标准定义的数据库间的sql语句差距不大，但是不同的数据库sql标准还是有差距的，那么我们手动修改起来会存在很大的困难，使用hibernate只需改变一下数据库方言即可搞定。用hibernate框架，数据库的移植变的非常方便。
但是hibernate也存在着诸多的不足，比如在实际开发过程中会生成很多不必要的sql语句耗费程序资源，优化起来也不是很方便，且对存储过程支持的也不够太强大。但是针对于hibernate它也提供了一些优化策略，比如说懒加载、缓存、策略模式等都是针对于它的优化方案。也可以自己拼装sql语句优化查询，所以单表操作使用hibernate的api，多表操作建议使用sql语句操作，增强性能，对于业务不发生变化的数据，可以使用缓存。
Mybatis 也是对jdbc的封装，但是封装的没有hibernate那么深，我们可以再配置文件中写sql语句，可以根据需求定制sql语句，数据优化起来较hibernate容易很多。
Mybatis要求程序员写sql的能力要相对使用hibernate的开发人员要高的多，且可移植性也不是很好。
涉及到大数据的系统使用Mybatis比较好，因为优化较方便。涉及的数据量不是很大且对优化没有那么高，可以使用hibernate
8、列举常用设计模式及开发中应用场景
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因
设计模式的分类
总体来说设计模式分为三大类：
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
一、Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点
二、Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。
三、Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。
四、Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示。
五、Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。
行为型有：
六、Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。
七、Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。
八、Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。 可以自己封装jdbc模板和hibernate模板
九、Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。
十、State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。
十一、Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户。
十二、China of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系
十三、Mediator，中介者模式：用一个中介对象封装一些列的对象交互。
十四、Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
十五、Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
十六、Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
结构型有：
十七、Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite使得用户对单个对象和组合对象的使用具有一致性。
十八、Facade，外观模式：为子系统中的一组接口提供一致的界面，fa?ade提供了一高层接口，这个接口使得子系统更容易使用。
十九、Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问
二十、Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
二十一、Decrator，装饰模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，Decorator模式相比生成子类更加灵活。
二十二、Bridge，桥模式：将抽象部分与它的实现部分相分离，使他们可以独立的变化。
二十三、Flyweight，享元模式
9、开发时候哪些模块的时候使用过存储过程，为什么？
*1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改，当即席SQL嵌入在应用程序内的时候，你可能会花费太多时间试图找到和调试嵌入的SQL。-- 一旦找到了bug，你可能就需要重新编译可执行程序，引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去，-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化，存储过程就会提升整个应用程序的可支持性。
*2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程，对网络以及应用程序的性能有正面影响，特别是当调用在一分钟内重复数千次时。
*3) 存储过程促进代码的可利用性。例如，如果你的网站应用程序使用一个下拉菜单来包含一组城市，并且这个下拉菜单用于很多网页，-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
*4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表，存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。-- 你可以把老的表换成新的，而且只要同样的列和数据类型返回给应用程序，则应用程序完全不知情。
*5) 与视图不同，存储过程可以利用流控制技术、临时表、表变量等。
*6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询，可能会注意到有时候从查询中返回结果所花的时间变化很大
企业开发存储过程的写法：参考：《存储过程》的文件夹：
例如：短信平台：
移动联通客户黑白名单查询
生成报告等
查看案例。
10、订单表数据量过大怎么处理。
如何应付表数据过大的查询问题?
一般来说,对于做B/S架构的朋友来说,更有机会遇到高并发的数据库访问情况,因为现在WEB的普及速度就像火箭升空,同时就会因为高访问量带来一系列性能问题,而数据库一直是用户与商人之间交流的重要平台.用户是没有耐心忍受一个查询需要用上10秒以上的，或者更少些，如果经常出现服务器死机或者是报查询超时，我想那将是失败的项目。做了几年的WEB工作,不才,一直没有遇到过大访问量或者是海量数据的情况.这里并不是说没有海量数据的项目就不是好项目,要看项目的应用场合.
最近做项目时,偶然得到了这个机会,在我工作过程中,本人发现的单表最大记录数高达9位数.像订单表什么的也有8位数.在查询订单的时候往往不能通过单表查询就能解决,还要和其它相关表进行关联查询.如此关联的表数据不大还好,一旦发生大表关联大表,在查询时就有可能出现慢长的等待。
主旨: 如何避免这种情况的发生呢?既然有了这样的数据,需求还是要实现,这里就我最近针对数据库的优化过程,我分两篇文章来说明下.
第一篇:如何尽量避免大表关联.
第二篇:对大表进行分区，水平分别和垂直分表.
背景:有两张表:
1:订单表：记录用户订单的详细信息.order,其中有一个会员卡号字段cardNo,订单产生时间.
2:会员表：记录会员相关信息.member,一个会员有一个代理号:proxyID,代理下面有许多的会员卡:cardNo,它们共用一个代理号.
两表通过cardNo来相关联.
需求:查询一个用户或者某些用户某一时间段所有会员卡产生的订单情况.
实现SQL:
select 字段 from order
inner join member on
order.cardNo=member.cardNo
and member.proxyID in('a-01',代理号二)
and 时间 between '20080101' and '20080131'
本人见解:我想一般的朋友看到这样的需求大多会写出这样的查询SQL,如果不喜欢用in或者认为in的性能不好的朋友可用union all 代替.SQL语句可以说简单的不能再简单了,本身并无问题,只是如果两表的数据都在百万以上,而且字段都特别多.此时如果只有索引的帮忙下并不一定能达到预期的效果.
解决方案一:利用表变量来替换大表关联,表变量的作用域为一个批处理,批处理完了,表变量也会随之失效,比起临时表有它独特的优点：不用手动去删除表变量以释放内存。
可行性:因为需求中的输出字段大多来自订单表,member表只起到数据约束的作用,和查询用户会员卡号的作用,所有可以先把代理的会员卡号先取到表变量中,然后利用带有卡号的表变量和订单表相关联查询.
declare @t table
(cardNo int)
insert @t
select cardNo from member where in('a-01',代理号二)
select 字段 from order
inner join @t on
[email protected] and 时间 between '20080101' and '20080131'
这种方法在查询人员比较多的时候特别有帮助.它要开发员根据实际情况详细比较,结果并不是统一的,不同的环境结果可能不一样。
解决方案二:利用索引视图来提高大表关联的性能.
可行性:一般在大表关联时,我们的输出列都远小于两表的字段合,像上面的member表只用到了其中的两个字段(cardNo,proxyID).设想一下,此时的member表如果只有这两个字段情况会不会好些呢?答案不言而喻.
视图这个名词在我以前对它的印象中,从来没有认为视图能优化查询,因为我认为视图对于数据库来说就是一个虚假表,在数据库中并无实际物理位置来存储数据.对于用户来说无非就是通过不同的视角来观看结果.视图数据的产生都是实时的,即当调用视图时,自动扩展视图,去运行里面相应的select语句.后来才知道在2000后的版本中视图分一般视图和索引视图,一般视图就是没有创建索引的我印象中的视图.而创建了视图后就称为索引视图.索引视图是物理存在的,可在视图上首先创建一个唯一的聚集索引,其它字段上也可创建非聚集索引.在不改变基础表的情况下,起到了优化的效果.
CREATE VIEW memberView
WITH SCHEMABINDING
AS
SELECT cardNo,proxyID from member
GO
--以会员卡号创建一个唯一聚集索引
CREATE UNIQUE CLUSTERED INDEX ix_member_cardNo
ON member (cardNo);
GO
注意:创建索引视图要点:
1: CREATE VIEW memberView后面要跟上WITH SCHEMABINDING
理由:? 使用 schemaname.objectname 明确识别视图所引用的所有对象,而不管是哪个用户访问该视图.
? 不会以导致视图定义非法或强制 SQL Server 在该视图上重新创建索引的方式,更改视图定义中所引用的对象.
2:视图上的第一个索引必须为 CLUSTERED 和 UNIQUE.
理由:必须为 UNIQUE 以便在维护索引视图期间,轻松地按键值查找视图中的记录,并阻止创建带有重复项目的视图(要求维护特殊的逻辑).必须为 CLUSTERED,因为只有聚集索引才能在强制唯一性的同时存储行.
3:以下情况可考虑创建索引视图:
? 可预先计算聚合并将其保存在索引中,从而在查询执行时,最小化高成本的计算.
? 可预先联接各个表并保存最终获得的数据集.
? 可保存联接或聚合的组合.
4:基础表的更新会引发索引视力的更新.
5:索引视图的创建同时会带来维护上的开销.
理由:1:因为索引视图是物理存在的.
2:要额外的维护索引.
实现:SQL:select 字段 from order
inner join memberView on
order.cardNo=member.cardNo
and member.proxyID=in('a-01',代理号二)
and 时间 between '20080101' and '20080131'
总结:两种解决方案来看,各有所长,一般可以优先考虑使用索引视图来优化大表关联.以上是本人对于如何尽量避免发生大表关联所采取的措施,望大家指教.
11、数据量大的表如果分表保存的话每张表保存多少条数据。为什么，如果不分表有解决方案没？
当一个应用的数据量大的时候，我们用单表和单库来存储会严重影响操作速度，如 mysql的myisam存储，我们经过测试，200w以下的时候，mysql的访问速度都很快，但是如果超过200w以上的数据，他的访问速度会急剧下 降，影响到我们webapp的访问速度，而且数据量太大的话，如果用单表存储，就会使得系统相当的不稳定，mysql服务很容易挂掉。所以当数据量超过 200w的时候，建议系统工程师还是考虑分表.
以下是几种常见的分表算法。
1.按自然时间来分表/分库;
如一个应用的数据在一年后数据量会达到200w左右，那么我们就可以考虑用一年的数据 来做为一个表或者库来存储，例如，表名为app，那么2010年的数据就是app_2010，app_2011;如果数据量在一个月就达到了200w左 右，那么我们就可以用月份来分，app_2010_01，app_2010_02.
2.按数字类型hash分表/分库;
如果我们要存储用户的信息，我们应用的注册量很大，我们用单表是不能满足存储需求的， 那么我们就可以用用户的编号来进行hash，常见的是用取余操作，如果我们要分30张表来存储用户的信息，那么用户编号为1的用户10=1，那么我们 就存在user_01表里，如用户的编号为500，那么5000=20，那么我们就将此用户的信息存储在user_20的表里.
3.按md5值来分表/分库;
我们假设要存储用户上传的文件，如果上传量大的话，也会带来系统的瓶颈问题，我们做过 试验，在一个文件夹下如果超过200个文件的话，文件的浏览效率会降低，当然，这个不属于我们本文讨论的范围，这块也要做散列操作.我们可以用文件的用户 名来md5或者用文件的md5校验值来做，我们就可以用md5的前5位来做hash，这样最多我们就可以得到5^5=3125个表，每次在存储文件的时 候，就可以用文件名的md5值的前5位来确定这个文件该存那张表.
4.实例:某微博的url加密算法和存储策略的猜想.
现在好多微博都用这样的url来访问，如果他们的域名为 www.example.com，那么如果你发微博的时候，你会发现你所发的url都变成了http://t.cn/Mx4ja1，这样的形式，他们是怎 么进行这样的转换呢?我猜想就是用到了我们上面讲的md5的存储和查找规则，用你发的url来进行md5，得到md5值之后，如我们例子来说，就会用前6 位来进行分表.
5.分表所带来的问题.
分表也会带来一系列的问题，如分页的实现，统计的实现，如果我们要做一个所有数据的分页，那么我们得每张表都得遍历一遍，这样访问效率会很低下.之前我尝试过用mysql的代理来实现，最终用tcsql来实现了.
6.分表算法的选择.
首先，分表适合于没有大的列表的应用来使用，要不然，会为这部分做好多额外的工作，如 果你的应用数据量不是特别大的话，最好别用分表。呵呵，以前在做项目的时候，一项目经理要我们设计了一个千万级别的分表算法，而应用的pv不会超过 100，总有点大炮打蚊子的感觉，而且因为分表，把整个项目的工期拖延了不少，得不偿失。
12、为了提高查询的效率 数据库方面和前台是怎么处理的
数据库：
- 使用缓存技术，在持久层或持久层之上做缓存（二级缓存，spring的缓存），eache和oscache等
- 使用索引库方式（lucene，solr，hibernate search），查询索引库，再查询数据库。
- 数据库查询时使用索引查询，恰当使用索引，必要时可建立多级索引
- 数据库表的大字段剥离，保证单条记录的数据量很小（截取字符串存取）。
- 分析Oracle的执行计划，通过表数据统计等方式协助数据库走正确的查询方式，该走索引就走索引，该走全表扫描就走全表扫描
- 表分区和拆分，无论是业务逻辑上的拆分（如一个月一张报表、分库）还是无业务含义的分区（如根据ID取模分区）
- 数据库集群，利用至少两台或者多台数据库服务器，构成一个虚拟单一数据库逻辑映像，像单数据库系统那样，向客户端提供透明的数据服务，完成负载均衡
- 字段冗余，减少跨库查询和大表连接操作
- 数据通过单个或多个JOB生成出来，减少实时查询
- 放弃关系数据库的某些特性，引入NoSQL数据库，redis技术
每个数据库平台上的SQL开发人员都是在困难中求得生存，我们总是一次又一次犯同样的错误，这是因为数据库领域还相对不成熟，是的，每个数据库厂商都在做着各种不同的努力，但作为开发人员仍然要克服各种问题，无论是在SQL Server，Oracle，DB2，Sybase，MySQL数据库，还是其它关系数据库平台上编写SQL代码，并发性、资源管理、空间管理和SQL运行速度总是困扰着开发人员。遗憾的是，其中部分问题的解决没有灵丹妙药，也几乎没有最佳实践。通常，开发人员有自己喜欢的SQL书写习惯，一般不愿意去研究其它可行方案，当然这可能是因为缺少培训的原因。我见得最多的就是在测试环境中SQL查询运行良好，但尚未在生产系统上进行试运行，就草草收场了，至于后来发现有问题，再被动式修改，因此最终用户就痛苦了。我不期望开发人员成为DBA，但我们编写代码时必须考虑生产时的问题，如果不在开发初期这么做，DBA发现后只能迫使我们返工。我们通常说数据库调试是一门技术，更是一门艺术，这是因为很少有现成的规则可以适应一切问题的解决，你在一个系统上解决的问题在另一个系统上可能就不是问题了，反之亦然。涉及到查询调整时，没有一个答案是完全正确的，但这并不意味着你应该放弃。适当遵循一些原则可以让工作变得更加轻松，本文就列举7个可以灵活运用的原则，它们可以帮助你提高SQL查询速度，当然这些技巧你可以咨询DBA获得更多的信息。
步骤/方法
1、用case代替update
要更新一条记录，我们立即会想到update，这个问题非常常见，许多开发人员经常忽视这个原则，因为使用update看起来非常自然，非常合乎逻辑。假设你从Customer表中提取记录，你想将超过10万美元的订单标记为“Preferred”，因此你会想到使用一条update语句将CustomerRank列更新为“Preferred”，问题是update语句是有日志的，这就意味着每条记录它会写两次，解决这个问题的办法就是在SQL查询中内嵌case语句，在向表写入“Preferred”标志前，它会用订单金额条件对每一行进行检查，满足条件的才会更新，性能的提升是惊人的。
2、不要盲目地重用代码
这个问题也非常常见，在工作中直接用别人写好的代码是一件痛快的事情，你知道这些代码可以查询出你需要的数据，但问题是往往有些数据不是你需要的，但我们常常不愿意做一下修改，因此返回的数据集往往是一个超集，很可能多用一个外连接或是一个where子句就可以解决问题，因此在复用代码时最好检查一下，如有必要略做适应性修改。
3、只提取你需要的列这个问题和2有点类似，但这次是指定具体的列。也许我们在使用select * 时感觉很畅快，多省事呀!如果要将每个列名都写出来，太麻烦了，这是很多人的想法，但这种想法是错误的，因为这样做会取出多余的数据列，我无数次看到犯这种错误的代码，曾经有一位开发人员对一张有120列，上百万行数据的表使用select * 查询，但他只会用到其中的三五列，这是对资源的极大浪费，我们建议拒绝书写select * ，你要什么就查询什么，多余的返回结果对你没用，虽然不影响你要实现的功能，但对数据库性能却有极大的影响。
4、尽可能只查询一次大表
这也是我看到很多人犯的错误，例如，某存储过程从一张上百万条记录的大表中取数据，开发人员想提取居住在加利福利亚且收入高于4万美元的客户信息，因此它先将居住在加利福利亚的客户取出放在一张临时表中，然后再查询收入高于4万美元的客户，将查询结果放入另一张临时表中，最后，他连接这两张临时表查询出最终的结果。可能有人认为我是在开玩笑吧?但事实是确实有人这么做，这应该在一个查询中就能完成，却查询了两次大表。有种稍微不同的情况是，当一个过程中的多个步骤需要大表的子集时，每一步可能都必须查询一次大表。避免多次查询的办法是持久化第一次查询的子集，然后将后面的步骤指向该持久化子集。
5、使用临时表
这个问题解决起来可能稍微有点麻烦，但其效果比较明显，其实在很多时候你都可以使用临时表，通过临时表可以有效地减少对大表的操作，如果你必须连接一个表到大表，并且在大表上有条件，这时就可以将大表中需要的数据输出到临时表中，然后再用该临时表进行连接，这样查询速度会有明显改进。如果你的存储过程中有多个查询需要需要连接到相同的表时，也可以使用临时表。
6、预存数据
这一条是我最喜欢的，因为它是一项很老的技术，常常被人们忽视，如果你有一个报表或存储过程需要连接大表，提前提取大表中的数据，持久化存储到另一张表中，报表就可以使用预存的数据集，从而提高整体执行效率。并不是所有时候你都有机会利用该技术，但一旦能利用上，你会发现它是节省服务器资源很有效的办法。但遗憾的是，很多开发人员都在尽力回避这种技术，实际上只需要创建一个视图就可以把问题解决了，但这种方法的问题是每个需要它的报表运行时都会执行一次，但对于同一个报表，假设10分钟前运行了一次，现在有人要再运行该报表，那么对大表的连接操作就可以避免掉了。我建议对那些经常被查询的表使用该技术将数据预存起来，可以节省大量的服务器资源。
7、分批删除和更新
这也是一个容易被忽视的技巧，对一个大表做数据删除或更新操作，如果操作不当可能是一场噩梦，问题是这两种操作都是单一的事务，如果你需要杀死它们，或它们在执行时系统遇到问题，必须全部回滚整个事务，这个时间可能非常长，这就是为什么我们在删除数十万条记录时，如果试图中途杀死进程几乎没用的原因，这些操作也会影响到其它事务，搞不好会造成死循环，因此应慎用。解决这个问题的办法就是分批少量删除或更新，首先，无论什么原因需要结束事务，只需要回滚少量的行，此外，小批量提交数据写入磁盘，对I/O的要求也更低，并发性可以大大提高。另外要提醒的是，执行删除和更新操作应尽量选择非高峰时段。
总结
遵循这些方法总是能收到效果，但在实践中，应该评估选用一种或几种最佳方案，大家一定要记住，没有那种办法是万能的。另外，这些技巧适用于所有数据库品种，因此你必须全部掌握!
前台：
- 使用页面静态化技术
- 使用自定义标签，不建议嵌套java代码
第一条：Make Fewer HTTP Requests 尽可能的减少HTTP的Request请求数。
80%的用户响应时间都是浪费在前端。而这些时间主要又是因为下载图片、样式表、JavaScript脚本、flash等文件造成的。减少这些资源文件的Request请求数将是提高网页显示效率的重点。
这里好像有个矛盾，就是如果我减少了很多的图片，样式，脚本或者flash，那么网页岂不是光秃秃的，那多难看呢？其实这是一个误解。我们只是说尽量的减少，并没有说完全不能使用。减少这些文件的Request请求数，当然也有一些技巧和建议的：
1：用一个大图片代替多个小图片。
这的确有点颠覆传统的思维了。以前我们一直以为多个小图片的下载速度之和会小于一个大图片的下载速度。但是现在利用httpwatch工具的对多个页面进行分析后的结果表明事实并不是这样。
第一张图是一个大小为40528bytes的337*191px的大图片的分析结果。
第二张图是一个大小为13883bytes的280*90px的小图片的分析结果。
一个大小为40528bytes的337*191px的大图片的分析结果（点击图片可以查看完整大图片）
一个大小为13883bytes的280*90px的小图片的分析结果（点击图片可以查看完整大图片）
第一张大图片花费时间为：
Blocked：13.034s
Send：0.001s
Wait：0.163s
Receive：4.596s
TTFB：0.164s
NetWork：4.760s
功耗时：17.795s
真正用于传输大文件花费的时间为Reveive时间，即4.596s，多数的时间是用来检索缓存和确定链接是否有效的Blocked时间，供花费13.034s，占总时间的73.2%。
第二张小图片花费时间为：
Blocked：16.274s
Send：小于0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗时：16.790s
真正用于传输文件的花费时间是Reveive时间，即0.397s，这的确要比刚才大文件的4.596s小很多。但是他的Blocked时间为16.274s，占总时间的97%。
如果这些数据还不够说服你的话，让我们看看下面这张图。这里列出了某个网页中所有图片中的花费时间示意图。当然，里面的图片有大有小，规格不一。
大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。
其中藏青色的为传输文件花费的Reveive时间，而前面白色的为检索缓存和确认链接是否有效的Blocked时间。铁一样的事实告诉我们：
· 大文件和小文件下载所需时间的确是不同的，差异的绝对值不大。而且下载所需时间占总耗费时间比例很小。
· 大约80%以上的时间是用来检索缓存和确定链接是否有效的Blocked时间。无论文件大小，这个时间的花费大致是相同的。而且所占总耗费时间的比例是极大的。
· 一个100k的大图片总耗费时间绝对大于4个25k的小图片的总耗费时间。而且主要差别就是4个小图片的Blocked时间绝对大于1个大图片的Blocked时间。
所以如果可能还是使用大图片来替代过多的琐碎的小图片吧。这也是为什么翻转门的效率要高于图片替换实现的滑动门的原因。
但是，请注意：也不能用太大的单张图片，因为那样会影响到用户体验。例如个几兆的背景图片的使用绝对不是一个好主意。
2：合并你的css文件。
图:合并与融合
我以前犯了一个错误，当时，我为了方便组织和规划样式表，将用于不同用途的样式表文件分离开来，形成不同的css文件。然后在页面中根据需要引用多个css文件。根据“尽可能的减少HTTP的Request请求数”准则我们知道，那样的确是不合理的，因为那样会产生更多的HTTP的Request请求数。从而降低网页的效率。所以，从提高网页效率的角度上而言，我们还是应该将所有的css写在同一个css文件中。但是问题又来了。那么怎么来很好的组织和规划样式表呢？这的确是个矛盾。我现在的做法是采用两套版本。编辑版和发布版。编辑版仍然使用多个css文件以便于规划和组织。而等到发布的时候，再将多个css文件合并到一个文件中去，从而达到减少HTTPRequest请求数的目的。
3：合并你的javascript文件。
原因和处理方法同上，不再赘言。
第二条：Use a Content Delivery Network 使用CDN
这个看上去好像很深奥的样子，但是只要结合中国的网络特色，这个便不难理解了。“北方服务器”、“南方服务器”、“电信服务器”、“网通服务器”……这些词听起来是那么熟悉和压抑。如果，一个北京的电信用户试图从广东的网通服务器上打开一个类似《壁纸合集》帖子的网页时，你就能很深刻的理解。
鉴于这个不是我们开发人员力所能及的准则，所以这里也就不多言了。
图:这个图也算有点中国特色了
第三条：Add an Expires Header 添加周期头
这个也并非开发人员来控制，而是网站服务器管理员的职责。所以，如果作为开发人员的你不了解和明白也没有关系。还是把这个准则告诉公司的网站服务器管理员。
第四条：Gzip Components 启用Gzip压缩
这个大家应该比较熟悉。Gzip的思想就是把文件先在服务器端进行压缩，然后再传输。这对于体积较大的纯文字型的文件有特效。鉴于这也并非开发人员，而是网站服务器管理员的工作范畴，这里就不详细讲解了。如果你对此感兴趣，可以资讯贵公司的网站服务器管理人员。
第五条：Put CSS at the Top 把CSS样式放在页面的上方。
无论是HTML还是XHTML还是CSS都是解释型的语言，而非编译型的。所以CSS到上方的话，那么浏览器解析结构的时候，就已经可以对页面进行渲染。这样就不会出现，页面结构光秃秃的先出来，然后CSS渲染，页面又突然华丽起来，这样太具有“戏剧性”的页面浏览体验了。
第六条：Move Scripts to the Bottom 将脚本放在底部
原因同第五条一样。只是脚本一般是用来于用户交互的。所以如果页面还没有出来，用户连页面都不知道什么样子，那谈交互简直就是扯谈。所以，脚本和CSS正好相反，脚本应该放在页面的底部。
第七条：Avoid CSS Expressions 避免使用CSS中的Expressions
图:CSS中的Expressions其实也是一种if判断
首先有必要先说明一下CSS Expressions是什么一个东西。其实它就像其它语言中的if……else……语句。这样在CSS中就可以进行简单的逻辑判断了。举个简单的例子——
这样css就可以根结一些情况分别使用不同的样式了。但是CSS中Expressions 的代价却是极高的。当你的页面需要根据判断来渲染效果的元素很多的时候，那么你的浏览器将长期处于假死状态，从而给用户带来极差的用户体验。
第八条：Make JavaScript and CSS External 将javascript和css独立成外部文件
这一条好像和第一条有点矛盾。的确，如果从HTTP的request请求数来讲的话，这样做的确是降低了效率。但是之所以这么做，是因为另外一个重要的考虑因素——缓存。因为外部的引用文件会被浏览器缓存，所以如果javascript和css体积较大的时候，我们将它们独立成外部文件。这样当用户只要浏览一次以后，这些体积较大的js和css文件就能被缓存起来，从而极高地提高用户再次访问时的效率。
第九条：Reduce DNS Lookups 减少DNS查询
DNS域名解析系统。大家都知道我们之所以能记住那么多的网址，是因为我们记住的都是单词，而非http://202.153.125.45这样的东西，而帮我们把那些单词和202.153.125.45这样的ip地址联系起来的就是DNS。那这一条对我们到底有什么真正意义上的指导意义呢？其实有两条：
1：如果不是必须，请不要把网站放到两台服务器上。
2：网页中的图片、css文件、js文件、flash文件等等，不要太多的分散在不同的网络空间中。这就是为什么那种只发一个网站中的壁纸图片的帖子，要比壁纸图片来源于不同网站的帖子显示要快得多的原因。
第十条：Minify JavaScript and CSS 减少JavaScript和CSS文件的体积
这点很好理解。在你的最终发布版本中把没有必要的空行、空格和注释全部去掉。显然手工去处理效率太低，好在网上到处都是用于压缩这些东西的工具。压缩JavaScript代码体积的工具随处可见，我便不再列举了，这里我只提供一个用于压缩css代码体积的在线工具网站——http://www.cssdrive.com/index.php/main/csscompressor
它提供了多种压缩方式，可以适应多种要求。
第十一条：Avoid Redirects 避免跳转
我只从网页开发人员的角度来解读此条。那么我们可以解读到什么东西呢？2点——
1：“此域名已过期，5秒钟以后，页面将跳转到http://www.xxxxxx.com/index.html页面”，这句话看起来的确很熟悉。但是，我就奇怪了，为什么不直接链接到那个页面呢？
2：一些链接地址请更明确的写出来。例如:将https://addons.mozilla.org/ 写成https://addons.mozilla.org（注意最后面一个“/”符号）。的确，这两个网址都能访问到我的博客，但是，事实上，它们是有区别的。https://addons.mozilla.org 的结果是个301响应，它会被重新指向https://addons.mozilla.org/。但是显然，中间多浪费了一些时间。
第十二条 Remove Duplicate Scripts 移除重复的脚本
图:对重复说“不！”
这个准则的道理很浅显，但是真正在工作中，很多人却因为“项目时间紧”、“太累了”、“初期没有规划好”……这样的理由搪塞过去了。你，的确可以找很多的理由不去处理这些多余重复的脚本代码，如果你的网站不需要更高的效率和后期维护的话。
也正是这点，我提醒大家一些，一些javascript框架、javascript包一定要慎用。至少要问一下：用了这个js kit 到底给我们多少方便，提高了多少工作效率。然后，再与它因为多余的、重复的代码带来的负面效果比较一下。
第十三条：Configure ETags 配置你的实体标签
首先来讲讲什么是Etag吧。Etag（Entity tags ）实体标签。这个tag和你在网上经常看到的标签云那种tag有点区别。这个Etag不是给用户用的，而是给浏览器缓存用的。Etag是服务器告诉浏览器缓存，缓存中的内容是否已经发生变化的一种机制。通过Etag，浏览器就可以知道现在的缓存中的内容是不是最新的，需不需要重新从服务器上重新下载。这和“Last-Modified”的概念有点类似。很遗憾作为网页开发人员对此无能为力。他依然是网站服务器人员的工作范畴。如果，你对此有兴趣，可以咨询贵公司的网站服务器管理员。
第十四条：Make Ajax Cacheable 上面的准则也适用Ajax
图:Ajax的使用要恰当
现在的Ajax好像有点被神话了，好像网页只要Ajax了，那么就不存在效率问题了。其实这是一种误解。拙劣的使用Ajax不会让你的网页效率更高，反而会降低你的网页效率。Ajax的确是个好东西，但是请不要过分的神话它。使用Ajax的时候也要考虑上面的那些准则。