#
为了使web应用能使用saas模式的大规模访问,必须实现应用的集群部署.要实现集群部署主要需要实现session共享机制,使得多台应用服务器之间会话统一, tomcat等多数服务都采用了session复制技术实现session的共享.
session复制技术的问题:
(1)技术复杂,必须在同一种中间件之间完成(如:tomcat-tomcat之间).
(2)在节点持续增多的情况下,session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时,性能下降更加显著.这种特性使得web应用的水平扩展受到了限制.
session共享的另一种思路就是把session集中起来管理,首先想到的是采用数据库来集中存储session,但数据库是文件存储相对内存慢了一个数量级,同时这势必加大数据库系统的负担.所以需要一种既速度快又能远程集中存储的服务,所以就想到了memcached.
memcached是什么?
memcached是由Danga Interactive开发的，高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。
memcached能缓存什么？
通过在内存里维护一个统一的巨大的hash表，Memcached能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。
memcached快么？
非常快。memcached使用了libevent（如果可以的话，在linux下使用epoll）来均衡任何数量的打开链接，使用非阻塞的网络I/O，对内部对象实现引用计数(因此，针对多样的客户端，对象可以处在多样的状态)， 使用自己的页块分配器和哈希表， 因此虚拟内存不会产生碎片并且虚拟内存分配的时间复杂度可以保证为O(1).。
Danga Interactive为提升Danga Interactive的速度研发了memcached。目前，LiveJournal.com每天已经在向一百万用户提供多达两千万次的页面访问。而这些，是由一个由web服务器和数据库服务器组成的集群完成的。memcached几乎完全放弃了任何数据都从数据库读取的方式，同时，它还缩短了用户查看页面的速度、更好的资源分配方式，以及memcache失效时对数据库的访问速度。
memcached的特点
memcached的缓存是一种分布式的，可以让不同主机上的多个用户同时访问， 因此解决了共享内存只能单机应用的局限，更不会出现使用数据库做类似事情的时候，磁盘开销和阻塞的发生。
使用memcached来存储session有两种方案:
(1)直接通过tomcat6的扩展机制实现.
参考: http://www.javaeye.com/topic/81641
(2)通过自己编写filter实现.
考虑到系统的扩展,我们采用这种方案.这样可以使session共享机制和中间件脱钩.
参考: http://www.javaeye.com/topic/82565
主要思路:
(1)继承重构HttpServletRequestWrapper,HttpSessionWrapper类,覆盖原来和session存取相关的方法呢,都通过SessionService类来实现.
(2)使用filter拦截cookie中的sessionId,通过sessionId构造新的HttpServletRequestWrapper对象,传给后面的应用.
(3)SessionService连接memcached服务,以sessionId作为key,存取的对象是一个map.map的内容即为session的内容.
使用过程注意几个问题和改进思路：
1、memcache的内存应该足够大，这样不会出现用户session从Cache中被清除的问题(可以关闭memcached的对象退出机制)。
2、如果session的读取比写入要多很多，可以在memcache前再加一个Oscache等本地缓存，减少对memcache的读操作，从而减小网络开销，提高性能。
3、如果用户非常多，可以使用memcached组，通过set方法中带hashCode，插入到某个memcached服务器
对于session的清除有几种方案:
(1)可以在凌晨人最少的时候，对memcached做一次清空。(简单)
(2)保存在缓存中的对象设置一个失效时间,通过过滤器获取sessionId的值,定期刷新memcached中的对象.长时间没有被刷新的对象自动被清除.(相对复杂,消耗资源)
提出问题：为啥要有双缓冲队列？
引用09年9月《程序员》上的一句话：双缓冲队列就是冲着同步/互斥的开销来的。我们知道，在多个线程并发访问同一个资源的时候，需要特别注意线程的同步问题。稍稍不注意，哦活，程序结果不正确了。最经典的就是“银行取钱”的例子，想想，都跟现金挂上钩了，看来这真不容忽视。
今天我们要谈的不是如何去给资源加锁解锁来解决同步问题，今天的重点在于，如何将线程同步的开销降低到我们力所能及的程度。如果你觉得，你可以通过增加硬件资源来弥补程序开销，那么，你将不可能成为一个优秀的程序员。
进入正题，先引入一个例子，两个实体：一个是玩具工厂，它的工作就是不停地生产玩具；另外一个实体就是小孩，它的工作就是不停地从工厂拿玩具。小孩不可能直接到工厂去“拿”玩具吧？呵呵，妈妈是绝对不会放心的。所以，我们有一个“搬运工”，搬运工自然要具备“存放”的功能，不然他怎么将玩具带给小孩呢，是吧。所以，我们先将搬运工定义为一个List，用来存放工厂生产出来的玩具。
代码如下
玩具类，定义一个玩具实体
public class Toy {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
接下来是玩具工厂，它得“不停地”生产，所以，把它设计成一个线程类
玩具工厂，将玩具对象，放到list中
public class Factory extends Thread{
public void run(){
while(true){
Toy t = new Toy ();
t.setName("玩具");
synchronized (Tools.lT){
Tools.lT.add(t);
}
try {
Thread.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
注意到，在上面这段代码当中，必须得用synchronized (Tools.lT)将Tools.lT给加锁。不然会出现线程同步问题（开销就在这里）。
再接下来，看看小孩是怎么“玩”玩具的：
小孩类，从list中取出玩具对象
public class Kid extends Thread {
long time1 = System.currentTimeMillis();
int count = 0;
public void run() {
while(true){
synchronized(Tools.lT){
if(Tools.lT.size()!=0)
Tools.lT.remove(0);
}
count++;
if(count==100000){
javax.swing.JOptionPane.showMessageDialog(null, "用时间: "+(System.currentTimeMillis()-time1));
System.exit(0);
}
}
}
}
当list不为空的时候，将list中的玩具对象，一个一个取出来，玩完！这个小孩可真够厉害的，呵呵。可以想象为，该类的工作就是不停地向list中取出玩具对象。OK，再来编写方法，如下
主方法
public class MainTest {
/**
* @param args
*/
public static void main(String[] args) {
Factory f = new Factory();
f.start();
Kid k = new Kid();
k.start();
}
}
最后是Tools类，他里面有个静态的List对象：
Tools类
public class Tools {
public static List<Toy>lT = new ArrayList<Toy>(10000);
}
这样，我们运行一下主方法，看看我们这位“天才”玩完100000个玩具，得花销多少的时间。
好，31毫秒。
这是我们的第一种解决方法，下面再来看第二种解决方法：
其实我们在Factory类和Kid类中都进行了同步处理，这样一来，浪费了很多时间，到底是不是这样的呢？我们可不可以直接用一个不用处理线程同步的容器来放Toy类对象呢？这样以来是不是就可以节省很多开销了？这个想法是有道理的，但是，事实是不是这样的呢？马上实践！
代码就不具体贴出来了，只是我们在Tools类中用到的是一个如下的对象
Public static LinkedBlockingQueue<Toy> lT= new LinkedBlockingQueue<Toy>(1000);
对，阻塞队列，这样我们就只管往里面取，从里面拿了，不用自己考虑同步问题，Factory类和Kid类中也不同特意去加关键字进行同步了。
那么这种方案的结果是多少呢？同样是100000个玩具，看结果
哦哦，变成16毫秒了，着实提高了不少效果呢。看来，在处理同步的时候挤时间，是有发展空间的，呵呵。
等等，有人要发话了，你在这磨叽了半天，还是没有说什么是双缓冲啊，对！有了前面的两种方案，我们再来看看“双缓冲队列”。
所谓双缓冲队列，自然起码要有两个队列吧，呵呵，在这个例子中，我们可以设计两个List来存放工厂生产出来的玩具对象。
下面分析一下：
两个List，一个用来存，一个用来取。有点迷糊？就是有一个listP从工厂那里得到玩具对象，另外一个listT就专门把它得到的玩具对象送去给 Kid类处理。当listT变成空的了以后，再将listP中在这段时间内取到的所有玩具对象放到listT中，好，这完了之后，他们两个就又各自干各自的去了:listP再去取，listT再去送。这样是不是就减少了很多次的线程同步呢？至少，在它们交换之前，listP是完全被工厂类线程占有，listT是完全被Kid类线程占有的，不用处理同步。只有在listT放完了，没得给了，再去跟ListP换过来，这个时候就要处理同步了。
跟实际联系一下，有两个搬运工A,B，A在工厂，专门从工厂取玩具；B在小孩子身边，专门送玩具给小孩玩。当B身上没有玩具了，自然要回A那里，把A身上的玩具全部拿过来，再来送给小孩玩。在A还有玩具的时候，A和B是在各自的线程里被处理的，即A在拿，B在给。不用担心同步问题。
这样以来，处理同步问题的次数是不是大大减少了呢？没错，就是这样的。那么怎么跟代码结合呢？
我们要设计一个监视线程，监视listP是不是空了，要是空了，把它同步起来，把listT也同步起来，让他们交换。完了就各自干各自的了。
我们来看看这个监视类：
public class DoubleBufferList {
private List<Object> lP;
private List<Object> lT;
private int gap;
/**
* 构造方法
*
* @param lP
* 用来存放对象的队列
* @param lT
* 用来取对象的队列
* @param gap
* 交换的间隔
*/
public DoubleBufferList(List lP, List lT, int gap) {
this.lP = lP;
this.lT = lT;
this.gap = gap;
}
public void check() {
Runnable runner = new Runnable() {
public void run() {
while (true) {
if (lT.size() == 0) {
synchronized (lT) {
synchronized (lP) {
lT.addAll(lP);
}
lP.clear();
}
}
try {
Thread.sleep(gap);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
};
Thread thread = new Thread(runner);
thread.start();
}
}
这个类中的线程方法就是用来交换的，目的就是为了减少处理同步的次数。这种方案中，Facotry类和Kid类跟前面单个List的情况差不多，就不再给出了。只是有一点要注意，Facory类中将玩具对象是放到了lP中，而Kid类中，也只是从lT中去取对象。看看Tools类中，多了一个变量：
Tools类，声明两个队列
public static List<Toy>lT = new ArrayList<Toy>(10000);
public static List<Toy>lP = new ArrayList<Toy>(10000);
同样是让我们的“天才”玩完100000个玩具，来看看运行需要的时间：
哈哈，似乎跟我们上面的第二种方案，单阻塞队列，没有太大的差异。怎么解释呢？
不用着急，来，我将额定的玩具量后多加个“0”，让他玩完1000000个！改一下单阻塞队列方案的输出结果，给他们一个标记。再来看看结果：
效果出来了吧，我们再加大量，让他们同时处理10000000个玩具对象：
充分说明，使用双缓冲队列，比单缓冲阻塞队列的效果要好，更别说单缓冲队列了。
总结：
从上面的分析，我们可以得知，在处理线程同步的时候，是要花费我们的时间的，虽然在有些时候，这样的花费是我们可以接受的，但是在很多情况下，如果我们能注意到这样的浪费，并且及时地完善我们的程序，这样可以更大限度地提高我们程序的运行效率。尤其是在大的程序里面，这样的效果体现得更明显。而往往越大的系统，对性能的要求也就越高。
android在处理一写图片资源的时候，会进行一些类型的转换，现在有空整理一下：
1、Drawable → Bitmap 的简单方法
((BitmapDrawable)res.getDrawable(R.drawable.youricon)).getBitmap();
2、Drawable → Bitmap
Java代码
public static Bitmap drawableToBitmap(Drawable drawable) {
Bitmap bitmap = Bitmap
.createBitmap(
drawable.getIntrinsicWidth(),
drawable.getIntrinsicHeight(),
drawable.getOpacity() != PixelFormat.OPAQUE ? Bitmap.Config.ARGB_8888
: Bitmap.Config.RGB_565);
Canvas canvas = new Canvas(bitmap);
//canvas.setBitmap(bitmap);
drawable.setBounds(0, 0, drawable.getIntrinsicWidth(), drawable.getIntrinsicHeight());
drawable.draw(canvas);
return bitmap;
}
3.Bitmap→Drawable 的简单方法
BitmapDrawable bitmapDrawable = (BitmapDrawable)bitmap;
Drawable drawable = (Drawable)bitmapDrawable;
Bitmap bitmap = new Bitmap (...);
Drawable drawable = new BitmapDrawable(bitmap);
3、从资源中获取Bitmap
Java代码
Resources res=getResources();
Bitmap bmp=BitmapFactory.decodeResource(res, R.drawable.pic);
4、Bitmap → byte[]
Java代码
private byte[] Bitmap2Bytes(Bitmap bm){
ByteArrayOutputStream baos = new ByteArrayOutputStream();
bm.compress(Bitmap.CompressFormat.PNG, 100, baos);
return baos.toByteArray();
}
5、 byte[] → Bitmap
Java代码
private Bitmap Bytes2Bimap(byte[] b){
if(b.length!=0){
return BitmapFactory.decodeByteArray(b, 0, b.length);
}
else {
return null;
}
}
修改TabHost默认样式
TabHost是Android提供的一个容器组件，利用它可以轻松地实现TAB界面，如下图所示：
但很多时候，默认的TAB样式并不符合软件的整体风格，这时候该怎么办呢？其实，我们可以编写XML对其样式进行修改。下面修改后的效果图：
1. TabHost布局文件 main.xml
<TabHost
android:id="@+id/tabhost"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<LinearLayout
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<TabWidget
android:id="@android:id/tabs"
android:layout_width="fill_parent"
android:layout_height="30dip"
android:background="#a0a0a0"
android:layout_weight="0" />
<FrameLayout
android:id="@android:id/tabcontent"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:layout_weight="1">
<ListView
android:id="@+id/user_list"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:divider="@drawable/divider_line"
android:cacheColorHint="#00000000" />
<ListView
android:id="@+id/article_list"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:divider="@drawable/divider_line"
android:cacheColorHint="#00000000" />
<ListView
android:id="@+id/feed_list"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:divider="@drawable/divider_line"
android:cacheColorHint="#00000000" />
<ListView
android:id="@+id/book_list"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:divider="@drawable/divider_line"
android:cacheColorHint="#00000000" />
</FrameLayout>
</LinearLayout>
</TabHost>
FrameLayout里有四个ListView 分别对应用户、文章、频道、图书。
TabWidget和FrameLayout的ID不能自己定义修改。
2. Activity后台代码
RelativeLayout articleTab = (RelativeLayout) LayoutInflater.from(this).inflate(R.layout.minitab, null);
TextView articleTabLabel = (TextView) articleTab.findViewById(R.id.tab_label);
articleTabLabel.setText("文章");
RelativeLayout feedTab = (RelativeLayout) LayoutInflater.from(this).inflate(R.layout.minitab, null);
TextView feedTabLabel = (TextView) feedTab.findViewById(R.id.tab_label);
feedTabLabel.setText("频道");
RelativeLayout bookTab = (RelativeLayout) LayoutInflater.from(this).inflate(R.layout.minitab, null);
TextView bookTabLabel = (TextView) bookTab.findViewById(R.id.tab_label);
bookTabLabel.setText("图书");
TabHost tabHost = (TabHost) findViewById(R.id.tabhost);
tabHost.setup();
tabHost.addTab(tabHost.newTabSpec("user").setIndicator(userTab).setContent(R.id.user_list));
tabHost.addTab(tabHost.newTabSpec("article").setIndicator(articleTab).setContent(R.id.article_list));
tabHost.addTab(tabHost.newTabSpec("feed").setIndicator(feedTab).setContent(R.id.feed_list));
tabHost.addTab(tabHost.newTabSpec("book").setIndicator(bookTab).setContent(R.id.book_list));
|
TabHost创建出来以后，必须先setup一下，tabHost.setup();
setIndicator方法设置的View其实就对应了TAB中的一个个选项卡，它们都是通过一个叫minitab的布局文件inflate出来的
3. 选项卡布局文件minitab.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:paddingLeft="5dip"
android:paddingRight="5dip">
<TextView android:id="@+id/tab_label"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:gravity="center"
android:textColor="#000000"
android:textStyle="bold"
android:background="@drawable/minitab" />
</RelativeLayout>
drawable/minitab是一个selector，指定了Tab选项卡的背景颜色。
4. selector文件 minitab.xml
<?xml version="1.0" encoding="utf-8"?>
<selector
xmlns:android="http://schemas.android.com/apk/res/android"
>
<item
android:state_selected="false"
android:drawable="@drawable/minitab_unselected"
>
</item>
<item
android:state_selected="true"
android:drawable="@drawable/minitab_default"
>
</item>
</selector>
minitab_unselected是一浅蓝色背景图片
minitab_default是一白色背景图片
摘 要 Java规则引擎是一种嵌入在Java程序中的组件，它的任务是把当前提交给引擎的Java数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。
引言
目前，Java社区推动并发展了一种引人注目的新技术——Java规则引擎（Rule Engine）。利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。
规则引擎的原理
1、基于规则的专家系统（RBES）简介
Java规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。为了更深入地了解Java规则引擎，下面简要地介绍基于规则的专家系统。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它们的结构如下系统所示：
图1 基于规则的专家系统构成
如图1所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、议程（Agenda）和执行引擎（Execution Engine）。推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。模式匹配器决定选择执行哪个规则，何时执行规则；议程管理模式匹配器挑选出来的规则的执行次序；执行引擎负责执行规则和其他动作。
和人类的思维相对应，推理引擎存在两者推理方式：演绎法（Forward-Chaining）和归纳法（Backward-Chaining）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是根据假设，不断地寻找符合假设的事实。Rete算法是目前效率最高的一个Forward-Chaining推理算法，许多Java规则引擎都是基于Rete算法来进行推理计算的。
推理引擎的推理步骤如下：
(1)将初始数据（fact）输入Working Memory。
(2)使用Pattern Matcher比较规则库（rule base）中的规则（rule）和数据（fact）。
(3)如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。
(4)解决冲突，将激活的规则按顺序放入Agenda。
(5)使用执行引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。
上述即是规则引擎的原始架构，Java规则引擎就是从这一原始架构演变而来的。
2、规则引擎相关构件
规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。
1)信息元（Information Unit）
信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。
2)信息服务（Information Services）
信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相对应的信息元。
3)规则集（Rule Set）
顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。
4)队列管理器（Queue Manager）
队列管理器用来管理来自不同信息服务的信息元对象的队列。
下面将研究规则引擎的这些相关构件是如何协同工作的。
如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。
图2 处理过程协作图
3、规则引擎的工作机制
下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续执行。这一过程将递归进行。
图3 规则引擎工作机制
Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引擎的结构示意图如图4所示。
图4 Java规则引擎工作机制
当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。
任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L. Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。
Java规则引擎API——JSR-94
为了使规则引擎技术标准化，Java社区制定了Java规则引擎API（JSR94）规范。它为Java平台访问规则引擎定义了一些简单的API。
Java规则引擎API在javax.rules包中定义，是访问规则引擎的标准企业级API。Java规则引擎API允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，就如同使用JDBC编写独立于厂商访问不同的数据库产品一样。Java规则引擎API包括创建和管理规则集合的机制，在工作区中添加，删除和修改对象的机制，以及初始化，重置和执行规则引擎的机制。
1、Java规则引擎API体系结构
Java规则引擎API主要由两大类API组成: 规则管理API(The Rules Administrator API)和运行时客户API(The Runtime Client API)。
1)规则管理API
规则管理API在javax.rules.admin中定义，包含装载规则以及与规则对应的动作(执行集 execution sets)以及实例化规则引擎。规则可以从外部资源中装载，比如URI，Input streams， XML streams和readers等等。同时规则管理API还提供了注册和取消注册执行集以及对执行集进行维护的机制。使用admin包定义规则有助于对客户访问运行规则进行控制管理，它通过在执行集上定义许可权使得未经授权的用户无法访问受控规则。
规则管理API使用类RuleServiceProvider来获得规则管理器(RuleAdministrator)接口的实例。该接口提供方法注册和取消注册执行集。规则管理器提供了本地和远程的RuleExecutionSetProvider，它负责创建规则执行集（RuleExecutionSet）。规则执行集可以从如XML streams， binary streams等来源中创建。这些数据来源及其内容经汇集和序列化后传送到远程的运行规则引擎的服务器上。在大多数应用程序中，远程规则引擎或远程规则数据来源的情况并不多。为了避免这些情况中的网络开销，API规定了可以从运行在同一JVM中规则库中读取数据的本地RuleExecutionSetProvider。规则执行集接口除了拥有能够获得有关规则执行集的方法，还有能够检索在规则执行集中定义的所有规则对象。这使得客户能够知道规则集中的规则对象并且按照自己需要来使用它们。
2)运行时客户API
运行时API在javax.rules包中定义，为规则引擎用户运行规则获得结果提供了类和方法。运行时客户只能访问那些使用规则管理API注册过的规则，运行时API帮助用户获得规则会话，并在这个会话中执行规则。
运行时API提供了对厂商规则引擎API的访问方法，这类似于JDBC。类RuleServiceProvider提供了对具体规则引擎实现的运行时和管理API的访问，规则引擎厂商通过该类将其规则引擎实现提供给客户，并获得RuleServiceProvider唯一标识规则引擎的URL。此URL的标准用法是使用类似于“com.mycompany.myrulesengine.rules.RuleServiceProvider”这样的Internet域名空间，这保证了访问URL的唯一性。类RuleServiceProvider内部实现了规则管理和运行时访问所需的接口。所有的RuleServiceProvider要想被客户所访问都必须用RuleServiceProviderManager进行注册，注册方式类似于JDBC API的DriverManager和Driver。
运行时接口是运行时API的关键部分。运行时接口提供了用于创建规则会话(RuleSession)的方法，规则会话是用来运行规则的。运行时API同时也提供了访问在service provider注册过的所有规则执行集(RuleExecutionSets)。规则会话接口定义了客户使用的会话的类型，客户根据自己运行规则的方式可以选择使用有状态会话或者无状态会话。无状态会话的工作方式就像一个无状态会话bean。客户可以发送单个输入对象或一列对象来获得输出对象。当客户需要一个与规则引擎间的专用会话时，有状态会话就很有用。输入的对象通过addObject() 方法可以加入到会话当中。同一个会话当中可以加入多个对象。对话中已有对象可以通过使用updateObject()方法得到更新。只要客户与规则引擎间的会话依然存在，会话中的对象就不会丢失。
RuleExecutionSetMetaData接口提供给客户让其查找规则执行集的元数据(metadata)。元数据通过规则会话接口(RuleSession Interface)提供给用户。
2、Java规则引擎API安全问题
规则引擎API将管理API和运行时API加以分开，从而为这些包提供了较好粒度的安全控制。规则引擎API并没有提供明显的安全机制，它可以和J2EE规范中定义的标准安全API联合使用。安全可以由以下机制提供，如Java 认证和授权服务 (JAAS)，Java加密扩展(JCE)，Java安全套接字扩展(JSSE)，或者其它定制的安全API。使用JAAS可以定义规则执行集的许可权限，从而只有授权用户才能访问。
3、异常与日志
规则引擎API定义了javax.rules.RuleException作为规则引擎异常层次的根类。所有其它异常都继承于这个根类。规则引擎中定义的异常都是受控制的异常(checked exceptions)，所以捕获异常的任务就交给了规则引擎。规则引擎API没有提供明确的日志机制，但是它建议将Java Logging API用于规则引擎API。
JSR 94 为规则引擎提供了公用标准API，仅仅为实现规则管理API和运行时API提供了指导规范，并没有提供规则和动作该如何定义以及该用什么语言定义规则，也没有为规则引擎如何读和评价规则提供技术性指导。
结束语
规则引擎技术为管理多变的业务逻辑提供了一种解决方案。规则引擎既可以管理应用层的业务逻辑又可以使表示层的页面流程可订制。这就给软件架构师设计大型信息系统提供了一项新的选择。而Java规则引擎在Java社区制定标准规范以后必将获得更大发展。
Drools规则引擎初学入门实例HelloWorld
（1）下载eclipse（www.eclipse.org），如果是一般的java开发，下载Eclipse IDE for Java Developers就行了，解压后即可使用；
（2）下载Drools（http://jboss.org/drools/downloads.html），目前最新版本是Drools 4.0.7 Binaries，下载后解压即可；
（3）之后下载eclipse的Drools插件，版本跟eclipse对应，目前有Drools 4.0.7 Eclipse 3.2 Workbench和Drools 4.0.7 Eclipse Europa 3.3 Workbench两种。
Drools插件解压后，将里面的org.drools.eclipse_4.0.7.jar文件copy到eclipse的plugins目录中，重启eclipse，在工具栏可以看到一个 图标，这就是Drools的工作台，之后就可通过这个按钮创建Drools resource文件了。
（4）开始Hello World
Java文件：DroolsTest.java
package com.sample;
import java.io.InputStreamReader;
import java.io.Reader;
import org.drools.RuleBase;
import org.drools.RuleBaseFactory;
import org.drools.WorkingMemory;
import org.drools.compiler.PackageBuilder;
import org.drools.rule.Package;
/**
* This is a sample file to launch a rule package from a rule source file.
*/
public class DroolsTest {
public static final void main(String[] args) {
try {
//load up the rulebase
RuleBase ruleBase = readRule();
WorkingMemory workingMemory = ruleBase.newStatefulSession();
//go !
Message message = new Message();
message.setMessage( "Hello World" );
message.setStatus( Message.HELLO );
workingMemory.insert( message );
workingMemory.fireAllRules();
} catch (Throwable t) {
t.printStackTrace();
}
}
/**
* Please note that this is the "low level" rule assembly API.
*/
private static RuleBase readRule() throws Exception {
//read in the source
Reader source = new InputStreamReader( DroolsTest.class.getResourceAsStream( "/Sample.drl" ) );
//optionally read in the DSL (if you are using it).
//Reader dsl = new InputStreamReader( DroolsTest.class.getResourceAsStream( "/mylang.dsl" ) );
//Use package builder to build up a rule package.
//An alternative lower level class called "DrlParser" can also be used...
PackageBuilder builder = new PackageBuilder();
//this wil parse and compile in one step
//NOTE: There are 2 methods here, the one argument one is for normal DRL.
builder.addPackageFromDrl( source );
//Use the following instead of above if you are using a DSL:
//builder.addPackageFromDrl( source, dsl );
//get the compiled package (which is serializable)
Package pkg = builder.getPackage();
//add the package to a rulebase (deploy the rule package).
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
ruleBase.addPackage( pkg );
return ruleBase;
}
public static class Message {
public static final int HELLO = 0;
public static final int GOODBYE = 1;
public static final int GAME_OVER = 2;
private String message;
private int status;
public String getMessage() {
return this.message;
}
public void setMessage(String message) {
this.message = message;
}
public int getStatus() {
return this.status;
}
public void setStatus( int status ) {
this.status = status;
}
}
}
选择插件Drools按钮里的"New Rule resource"，建立规则（rule）文件：Sample.drl
package com.sample
import com.sample.DroolsTest.Message;
rule "Hello World"
when
m : Message( status == Message.HELLO, message : message )
then
System.out.println( message );
m.setMessage( "Goodbye cruel world" );
m.setStatus( Message.GOODBYE );
update( m );
end
rule "GoodBye"
no-loop true
when
m : Message( status == Message.GOODBYE, message : message )
then
System.out.println( message );
m.setStatus(Message.GAME_OVER);
m.setMessage("game over now!");
update( m );
end
rule "game over"
when
m : Message( status == Message.GAME_OVER)
then
System.out.println( m.getMessage() );
end
注意：文件要放在相应的包里，然后编译—执行，当时出现了错误，查找资料，还需要加载包，包括：
<1> Drools 4.0.7目录下的drools-core-4.0.7.jar，drools-compiler-4.0.7.jar
<2> Drools 4.0.7\lib目录下的antlr-runtime-3.0.jar，mvel-1.3.1-java1.4.jar
<3>以及eclipse\plugins目录下的org.eclipse.jdt.core_3.2.3.v_686_R32x.jar（不同版本，包名会稍有不同）。
重新运行，应该就不会有错了。执行结果如下：
Hello World
Goodbye cruel world
game over now!
Oracle JOB 间隔时间详解
INTERVAL参数设置：
每天运行一次 'SYSDATE + 1'
每小时运行一次 'SYSDATE + 1/24'
每10分钟运行一次 'SYSDATE + 10/（60*24）'
每30秒运行一次 'SYSDATE + 30/(60*24*60)'
每隔一星期运行一次 'SYSDATE + 7'
每个月最后一天运行一次 'TRUNC(LAST_DAY(ADD_MONTHS(SYSDATE,1))) + 23/24'
每年1月1号零时 'TRUNC(LAST_DAY(TO_DATE(EXTRACT(YEAR from SYSDATE)||'12'||'01','YYYY-MM-DD'))+1)'
每天午夜12点 'TRUNC(SYSDATE + 1)'
每天早上8点30分 'TRUNC(SYSDATE + 1) + (8*60+30)/(24*60)'
每星期二中午12点 'NEXT_DAY(TRUNC(SYSDATE ), ''TUESDAY'' ) + 12/24'
每个月第一天的午夜12点 'TRUNC(LAST_DAY(SYSDATE ) + 1)'
每个月最后一天的23点 'TRUNC (LAST_DAY (SYSDATE)) + 23 / 24'
每个季度最后一天的晚上11点 'TRUNC(ADD_MONTHS(SYSDATE + 2/24, 3 ), 'Q' ) -1/24'
每星期六和日早上6点10分 'TRUNC(LEAST(NEXT_DAY(SYSDATE, ''S ......
- 堆大小设置
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。
典型设置：
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
- java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
- 回收器选择
JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。
- 吞吐量优先的并行收集器
如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。
典型配置：
- java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
- 响应时间优先的并发收集器
如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置：
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
- 辅助信息
JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
- -XX:+PrintGC
输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
- -XX:+PrintGCDetails
输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
- -XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用
输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
- -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用
输出形式：Application time: 0.5291524 seconds
- -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式：Total time for which application threads were stopped: 0.0468229 seconds
- -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式：
34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs]
- -Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。
- 常见配置汇总
- 堆设置
- -Xms:初始堆大小
- -Xmx:最大堆大小
- -XX:NewSize=n:设置年轻代大小
- -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
- -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
- -XX:MaxPermSize=n:设置持久代大小
- 收集器设置
- -XX:+UseSerialGC:设置串行收集器
- -XX:+UseParallelGC:设置并行收集器
- -XX:+UseParalledlOldGC:设置并行年老代收集器
- -XX:+UseConcMarkSweepGC:设置并发收集器
- 垃圾回收统计信息
- -XX:+PrintGC
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -Xloggc:filename
- 并行收集器设置
- -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
- -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
- -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
- 并发收集器设置
- -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
- -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
四、调优总结
- 年轻代大小选择
- 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
- 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
- 年老代大小选择
- 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
- 并发垃圾收集信息
- 持久代并发收集次数
- 传统GC信息
- 花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间，一般会提高应用的效率
- 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
- 较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
- -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
数据类型
Java虚拟机中，数据类型可以分为两类：基本类型和引用类型。基本类型的变量保存原始值，即：他代表的值就是数值本身；而引用类型的变量保存引用值。“引用值”代表了某个对象的引用，而不是对象本身，对象本身存放在这个引用值所表示的地址的位置。
基本类型包括：byte,short,int,long,char,float,double,Boolean,returnAddress
引用类型包括：类类型，接口类型和数组。
堆与栈
堆和栈是程序运行的关键，很有必要把他们的关系说清楚。
栈是运行时的单位，而堆是存储的单位。
栈解决程序的运行问题，即程序如何执行，或者说如何处理数据；堆解决的是数据存储的问题，即数据怎么放、放在哪儿。
在Java中一个线程就会相应有一个线程栈与之对应，这点很容易理解，因为不同的线程执行逻辑有所不同，因此需要一个独立的线程栈。而堆则是所有线程共享的。栈因为是运行单位，因此里面存储的信息都是跟当前线程（或程序）相关信息的。包括局部变量、程序运行状态、方法返回值等等；而堆只负责存储对象信息。
为什么要把堆和栈区分出来呢？栈中不是也可以存储数据吗？
第一，从软件设计的角度看，栈代表了处理逻辑，而堆代表了数据。这样分开，使得处理逻辑更为清晰。分而治之的思想。这种隔离、模块化的思想在软件设计的方方面面都有体现。
第二，堆与栈的分离，使得堆中的内容可以被多个栈共享（也可以理解为多个线程访问同一个对象）。这种共享的收益是很多的。一方面这种共享提供了一种有效的数据交互方式(如：共享内存)，另一方面，堆中的共享常量和缓存可以被所有栈访问，节省了空间。
第三，栈因为运行时的需要，比如保存系统运行的上下文，需要进行地址段的划分。由于栈只能向上增长，因此就会限制住栈存储内容的能力。而堆不同，堆中的对象是可以根据需要动态增长的，因此栈和堆的拆分，使得动态增长成为可能，相应栈中只需记录堆中的一个地址即可。
第四，面向对象就是堆和栈的完美结合。其实，面向对象方式的程序与以前结构化的程序在执行上没有任何区别。但是，面向对象的引入，使得对待问题的思考方式发生了改变，而更接近于自然方式的思考。当我们把对象拆开，你会发现，对象的属性其实就是数据，存放在堆中；而对象的行为（方法），就是运行逻辑，放在栈中。我们在编写对象的时候，其实即编写了数据结构，也编写的处理数据的逻辑。不得不承认，面向对象的设计，确实很美。
在Java中，Main函数就是栈的起始点，也是程序的起始点。
程序要运行总是有一个起点的。同C语言一样，java中的Main就是那个起点。无论什么java程序，找到main就找到了程序执行的入口：）
堆中存什么？栈中存什么？
堆中存的是对象。栈中存的是基本数据类型和堆中对象的引用。一个对象的大小是不可估计的，或者说是可以动态变化的，但是在栈中，一个对象只对应了一个4btye的引用（堆栈分离的好处：））。
为什么不把基本类型放堆中呢？因为其占用的空间一般是1~8个字节——需要空间比较少，而且因为是基本类型，所以不会出现动态增长的情况——长度固定，因此栈中存储就够了，如果把他存在堆中是没有什么意义的（还会浪费空间，后面说明）。可以这么说，基本类型和对象的引用都是存放在栈中，而且都是几个字节的一个数，因此在程序运行时，他们的处理方式是统一的。但是基本类型、对象引用和对象本身就有所区别了，因为一个是栈中的数据一个是堆中的数据。最常见的一个问题就是，Java中参数传递时的问题。
Java中的参数传递时传值呢？还是传引用？
要说明这个问题，先要明确两点：
1. 不要试图与C进行类比，Java中没有指针的概念
2. 程序运行永远都是在栈中进行的，因而参数传递时，只存在传递基本类型和对象引用的问题。不会直接传对象本身。
明确以上两点后。Java在方法调用传递参数时，因为没有指针，所以它都是进行传值调用（这点可以参考C的传值调用）。因此，很多书里面都说Java是进行传值调用，这点没有问题，而且也简化的C中复杂性。
但是传引用的错觉是如何造成的呢？在运行栈中，基本类型和引用的处理是一样的，都是传值，所以，如果是传引用的方法调用，也同时可以理解为“传引用值”的传值调用，即引用的处理跟基本类型是完全一样的。但是当进入被调用方法时，被传递的这个引用的值，被程序解释（或者查找）到堆中的对象，这个时候才对应到真正的对象。如果此时进行修改，修改的是引用对应的对象，而不是引用本身，即：修改的是堆中的数据。所以这个修改是可以保持的了。
对象，从某种意义上说，是由基本类型组成的。可以把一个对象看作为一棵树，对象的属性如果还是对象，则还是一颗树（即非叶子节点），基本类型则为树的叶子节点。程序参数传递时，被传递的值本身都是不能进行修改的，但是，如果这个值是一个非叶子节点（即一个对象引用），则可以修改这个节点下面的所有内容。
堆和栈中，栈是程序运行最根本的东西。程序运行可以没有堆，但是不能没有栈。而堆是为栈进行数据存储服务，说白了堆就是一块共享的内存。不过，正是因为堆和栈的分离的思想，才使得Java的垃圾回收成为可能。
Java中，栈的大小通过-Xss来设置，当栈中存储数据比较多时，需要适当调大这个值，否则会出现java.lang.StackOverflowError异常。常见的出现这个异常的是无法返回的递归，因为此时栈中保存的信息都是方法返回的记录点。
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。
7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限(只有主键索引)。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度;如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。