BufferedReader buf =
new BufferedReader(new InputStreamReader(System.in));

此时Eclipse会警示说没有汇入类别，这时我们只要按下Ctrl+Shift+O
，它就会自动帮我们Import类别。

查看使用类别的原始码：Ctrl+鼠标左键点击
简易说明：可以看到您所使用类别的原始码。

将选取的文字批注起来：Ctrl+/
简易说明：Debug时很方便。
修改处：窗口->喜好设定->工作台->按键->程序代码->批注

视景切换：Ctrl+F8
个人习惯：Alt+S。
修改处：窗口->喜好设定->工作台->按键->窗口->下一个视景。
简易说明：可以方便我们快速切换编辑、除错等视景。

密技篇：
一套Eclipse可同时切换，英文、繁体、简体显示：
1.首先要先安装完中文化包。
2.在桌面的快捷方式后面加上参数即可，
英文-> -nl "zh_US"
繁体-> -nl "zh_TW"
简体-> -nl "zh_CN"。
(其它语系以此类推)
像我2.1.2中文化后，我在我桌面的Eclipse快捷方式加入参数-n1 "zh_US"。
"C:\Program Files\eclipse\eclipse.exe" -n "zh_US"
接口就会变回英文语系噜。

利用Eclipse，在Word编辑文书时可不必将程序代码重新编排：
将Eclipse程序编辑区的程序代码整个复制下来(Ctrl+C)，直接贴(Ctrl+V)到
Word或WordPad上，您将会发现在Word里的程序代码格式，跟Eclipse
所设定的完全一样，包括字型、缩排、关键词颜色。我曾试过JBuilder
、GEL、NetBeans...使用复制贴上时，只有缩排格式一样，字型、颜
色等都不会改变。

外挂篇：
外挂安装：将外挂包下载回来后，将其解压缩后，您会发现features、
plugins这2个数据夹，将里面的东西都复制或移动到Eclipse的features
、plugins数据夹内后，重新启动Eclipse即可。

让Eclipse可以像JBuilderX一样使用拖拉方式建构GUI的外挂：
1.Jigloo SWT/Swing GUI Builder ：
http://cloudgarden.com/jigloo/index.html
下载此版本：Jigloo plugin for Eclipse (using Java 1.4 or 1.5)
安装后即可由档案->新建->其它->GUI Form选取要建构的GUI类型。

2.Eclipse Visual Editor Project：
http://www.eclipse.org/vep/
点选下方Download Page，再点选Latest Release 0.5.0进入下载。
除了VE-runtime-0.5.0.zip要下载外，以下这2个也要：
EMF build 1.1.1: (build page) (download zip)
GEF Build 2.1.2: (build page) (download zip)

3.0 M8版本，请下载：
EMF build I200403250631
GEF Build I20040330
VE-runtime-1.0M1

安装成功后，便可由File->New->Visual Class开始UI设计。
安装成功后，即可由新建->Java->AWT与Swing里选择
所要建构的GUI类型开始进行设计。VE必须配合着对应
版本，才能正常使用，否则即使安装成功，使用上仍会
有问题。

使用Eclipse来开发JSP程序：
外挂名称：lomboz(下载页面)
http://forge.objectweb.org/project/showfiles.php?group_id=97
请选择适合自己版本的lomboz下载，lomboz.212.p1.zip表示2.1.2版，
lomboz.3m7.zip表示M7版本....以此类推。
lomboz安装以及设置教学：
Eclipse 开发JSP- 教学文件

Java 转exe篇：
实现方式：Eclipse搭配JSmooth(免费)。
1.先由Eclipse制作包含Manifest的JAR。
制作教学
2. 使用JSmooth将做好的JAR包装成EXE。
JSmooth下载页面：
http://jsmooth.sourceforge.net/index.php
3. 制作完成的exe文件，可在有装置JRE的Windows上执行。

Eclipse-Java编辑器最佳设定：
编辑器字型设定：工作台->字型->Java编辑器文字字型。
(建议设定Courier New -regular 10)

编辑器相关设定：窗口->喜好设定->Java->编辑器

外观：显示行号、强调对称显示的方括号、强调显示现行行、
显示打印边距，将其勾选，Tab宽度设4，打印编距字段设80。
程序代码协助：采预设即可。
语法：可设定关键词、字符串等等的显示颜色。
附注：采预设即可。
输入：全部字段都勾选。
浮动说明：采预设即可。
导览：采预设即可。

使自动排版排出来的效果，最符合Java设计惯例的设定：
自动排版设定：窗口->喜好设定->Java->程序代码制作格式。

换行：全部不勾选。
分行：行长度上限设：80。
样式：只将强制转型后插入空白勾选。
内缩空格数目：设为4。

Eclipse的教学文件：
Eclipse 3.0 系列热键表 - 中英对照解说版 (by sungo) ~New~
Window+GCC+CDT 用Eclipse 开发C 、C++ (by sungo) ~New~

其它：
扩充Eclipse 的Java 开发工具( 中文)
使用Eclipse 开发J2EE 应用程序( 中文)
使用Eclipse 平台进行除错( 中文)
用Eclipse 进行XML 开发( 中文)
开发Eclipse 外挂程序( 中文)
国际化您的Eclipse 外挂程序( 英文)
将Swing 编辑器加入Eclipse( 英文)
如何测试你的Eclipse plug-in 符合国际市场需求( 英文)

Eclipse 的相关网站：
http://eclipse-plugins.2y.net/eclipse/index.jsp
http://www.eclipseplugincentral.com/
Eclipse 相关教学[ 简体]

出处 CN-JAVA翻译： 孤魂一笑     

什么是持久化和对象关系映射ORM技术

http://www.volitation.net/Article/print.asp?SelectID=7
Hibernate技术主题
http://www.csdn.net/subject/hibernate/
电子书
http://www.00083.com/Soft/ShowElite.asp?page=3
值得关注的持久化技术： hibernate
http://www.huihoo.com/java/hibernate/index.htm

java中的reflect机制!!!
http://www.blogjava.net/anders0913/archive/2005/11/17/20185.html

Java中的类反射机制
http://www.daima.com.cn/Info/121/Info36999/

Spring Framework 开发参考手册
http://www.jactiongroup.net/reference/html/index.html

java.util包（二）
http://teach.yuxinhuayuan.com/A200507/2005-07-24/165807.html

【JDK核心API】

http://teach.yuxinhuayuan.com/Dev/Programme/Java/api/
一个中年职场老油子对应届生谈招聘
http://blog.chinaitlab.com/user1/170241/archives/2006/50082.html

String类、StringBuffer类、Math类
http://teach.yuxinhuayuan.com/A200507/2005-07-24/165769.html
深入理解Collections API
http://teach.yuxinhuayuan.com/A200507/2005-07-24/165747.html
使用java.util.Timer
http://teach.yuxinhuayuan.com/A200507/2005-07-24/165745.html
初识Java内部类
http://www.frontfree.net/view/article_704.html
JAVA内部类的基本特征
http://www.blogjava.net/justinlei/articles/19873.html
static内部类
http://www.koyoyo8.com/phpcms/data/2006/0222/article_1118.htm
http://www.chinaspx.com/archive/java/15304.htm

正确使用ArrayList和LinkedList—性能的改进 
http://dev.csdn.net/article/19/19387.shtm

简述：ArrayList的查找速度明显优于LinkedList，但是LinkedList的插入，删除等操作的速度明显优于ArrayList；
HashMap 的查找速度高于ArrayList；

Java Gossip: LinkedList
http://www.jwit.edu.tw/~imitclub/javatech-2/JavaGossip-V2/JavaGossip-V2/LinkedList.htm

JAVA面试题-COREJAVA部分
http://www.513pc.net/vc/java/200603/182.html
全面接触Java集合框架[转]
http://blog.tomxp.com/view/453.html

java性能
http://bingchen2005.blogchina.com/3461257.html

Java线程总结
http://java.chinaitlab.com/line/373702.html

JAVA学习
http://feng5534.blog.my5q.com/

0.Eclipse下载
EMF,GEF - Graphical Editor Framework,UML2,VE - Visual Editor都在这里下载
http://www.eclipse.org/downloads/index.php
 
0.5.lomboz J2EE插件,开发JSP,EJB
http://forge.objectweb.org/projects/lomboz
1.MyEclipse J2EE开发插件，支持SERVLET/JSP/EJB/数据库操纵等
http://www.myeclipseide.com
 
2.Properties Editor  编辑java的属性文件，并可以自动存盘为Unicode格式
http://propedit.sourceforge.jp/index_en.html
 
3.Colorer Take  为上百种类型的文件按语法着色
http://colorer.sourceforge.net/
 
4.XMLBuddy 编辑xml文件
http://www.xmlbuddy.com
 
5.Code Folding  加入多种代码折叠功能（比eclipse自带的更多）
http://www.coffee-bytes.com/servlet/PlatformSupport
 
6.Easy Explorer  从eclipse中访问选定文件、目录所在的文件夹
http://easystruts.sourceforge.net/
 
7.Fat Jar 打包插件，可以方便的完成各种打包任务，可以包含外部的包等
http://fjep.sourceforge.net/
 
8.RegEx Test 测试正则表达式
http://brosinski.com/stephan/archives/000028.php
 
9.JasperAssistant 报表插件（强，要钱的）
http://www.jasperassistant.com/
 
10.Jigloo GUI Builder ＪＡＶＡ的ＧＵＩ编辑插件
http://cloudgarden.com/jigloo/
 
11.Profiler 性能跟踪、测量工具，能跟踪、测量ＢＳ程序
http://sourceforge.net/projects/eclipsecolorer/
 
12.AdvanQas 提供对if/else等条件语句的提示和快捷帮助（自动更改结构等）
http://eclipsecolorer.sourceforge.net/advanqas/index.html
 
13.Log4E Log4j插件，提供各种和Log4j相关的任务，如为方法、类添加一个logger等
http://log4e.jayefem.de/index.php/Main_Page
 
14.VSSPlugin VSS插件
http://sourceforge.net/projects/vssplugin
 
15.Implementors 提供跳转到一个方法的实现类，而不是接中的功能（实用!）
http://eclipse-tools.sourceforge.net/implementors/
 
16.Call Hierarchy 显示一个方法的调用层次（被哪些方法调，调了哪些方法）
http://eclipse-tools.sourceforge.net/call-hierarchy/index.html
 
17.EclipseTidy 检查和格式化HTML/XML文件
http://eclipsetidy.sourceforge.net/
 
18.Checkclipse 检查代码的风格、写法是否符合规范
http://www.mvmsoft.de/content/plugins/checkclipse/checkclipse.htm
 
19.Hibernate Synchronizer Hibernate插件，自动映射等
http://www.binamics.com/hibernatesync/
 
20.VeloEclipse  Velocity插件
http://propsorter.sourceforge.net/
 
21.EditorList 方便的列出所有打开的Editor
http://editorlist.sourceforge.net/
 
22.MemoryManager 内存占用率的监视
http://cloudgarden.com/memorymanager/
 
23.swt-designer java的GUI插件
http://www.swt-designer.com/
 
24.TomcatPlugin 支持Tomcat插件
http://www.sysdeo.com/eclipse/tomcatPlugin.html
 
25.XML Viewer
http://tabaquismo.freehosting.net/ignacio/eclipse/xmlview/index.html
 
26.quantum 数据库插件
http://quantum.sourceforge.net/
 
27.Dbedit 数据库插件
http://sourceforge.net/projects/dbedit
 
28.clay.core 可视化的数据库插件
http://www.azzurri.jp/en/software/index.jsp
http://www.azzurri.jp/eclipse/plugins
 
29.hiberclipse hibernate插件
http://hiberclipse.sourceforge.net
http://www.binamics.com/hibernatesync
 
30.struts-console Struts插件
http://www.jamesholmes.com/struts/console/
 
31.easystruts Struts插件
http://easystruts.sourceforge.net
 
32.veloedit Velocity插件
http://veloedit.sourceforge.net/
 
33.jalopy 代码整理插件
http://jalopy.sourceforge.net/
 
34.JDepend 包关系分析
http://andrei.gmxhome.de/jdepend4eclipse/links.html
 
35.Spring IDE Spring插件
http://springide-eclip.sourceforge.net/updatesite/
 
36.doclipse 可以产生xdoclet 的代码提示
http://beust.com/doclipse/

不要重新分配被锁定对象的对象引用

synchronized 关键字锁定对象。对象是在 synchronized 代码内部被锁定的，这一点对此对象以及您对其对象引用所作的更改意味着什么呢？对一个对象作同步处理只锁定该对象。但是，必须注意不要重新分配被锁定对象的对象引用。那么如果这样做会发生什么情况呢？请考虑下面这段代码，它实现了一个 Stack：

class Stack
{
private int StackSize = 10;
private int[] intArr = new int[stackSize];
private int index; //Stack 中的下一个可用位置。

public void push(int val)
{
synchronized(intArr) {
//如果已满，则重新分配整数数组（即我们的 Stack）。
if (index == intArr.length)
{
stackSize *= 2;
int[] newintArr == new int[stackSize];
System.arraycopy(intArr, 0, newintArr, 0, intArr.length);
intArr = newintArr;
}
intArr[index] == val;
index++;
}
}

public int pop()
{
int retval;
synchronized(intArr) {
if (index > 0)
{
retval = intArr[index-1]; //检索值，
index--; //并使 Stack 减少 1 个值。
return retval;
}
}
throw new EmptyStackException();
}
//...
}


这段代码用数组实现了一个 Stack。创建了一个初始大小为 10 的数组来容纳整数值。此类实现了 push 和 pop 方法来模拟 Stack 的使用。在 push 方法中，如果数组中没有更多的空间来容纳压入的值，则数组被重新分配以创建更多的存储空间。（故意没有用 Vector 来实现这个类。Vector 中不能储存基本类型。）

请注意，这段代码是要由多个线程进行访问的。push 和 pop 方法每次对该类的共享实例数据的访问都是在 synchronized 块内完成的。这样就保证了多个线程不能并发访问此数组而生成不正确的结果。

这段代码有一个主要的缺点。它对整数数组对象作了同步处理，而这个数组被 Stack 类的 intArr 所引用。当 push 方法重新分配此整数数组时，这个缺点就会显露出来。当这种情况发生时，对象引用 intArr 被重新指定为引用一个新的、更大的整数数组对象。请注意，这是在 push 方法的 synchronized 块执行期间发生的。此块针对 intArr 变量引用的对象进行了同步处理。因此，在这段代码内锁定的对象不再被使用。请考虑以下的事件序列：

线程 1 调用 push 方法并获得 intArr 对象的锁。


线程 1 被线程 2 抢先。


线程 2 调用 pop 方法。此方法因试图获取当前线程 1 在 push 方法中持有的同一个锁而阻塞。


线程 1 重新获得控制并重新分配数组。intArr 变量现在引用一个不同的变量。


push 方法退出并释放它对原来的 intArr 对象的锁。


线程 1 再次调用 push 方法并获得新 intArr 对象的锁。


线程 1 被线程 2 抢先。


线程 2 获得旧 intArr 对象的对象锁并试图访问其内存。


现在线程 1 持有由 intArr 引用的新对象的锁，线程 2 持有由 intArr 引用的旧对象的锁。因为两个线程持有不同的锁，所以它们可以并发执行 synchronized push 和 pop 方法，从而导致错误。很明显，这不是所希望的结果。

这个问题是因 push 方法重新分配被锁定对象的对象引用而造成的。当某个对象被锁定时，其他线程可能在同一个对象锁上被阻塞。如果将被锁定对象的对象引用重新分配给另一个对象，其他线程的挂起锁则是针对代码中已不再相关的对象的。

您可以这样修正这段代码，去掉对 intArr 变量的同步，而对 push 和 pop 方法进行同步。通过将 synchronized 关键字添加为方法修饰符即可实现这一点。正确的代码如下所示：

class Stack
{
//与前面相同...
public synchronized void push(int val)
{
//如果为空，则重新分配整数数组（即我们的 Stack）。
if (index == intArr.length)
{
stackSize *= 2;
int[] newintArr = new int[stackSize];
System.arraycopy(intArr, 0, newintArr, 0, intArr.length);
intArr = newintArr;
}
intArr[index]= val;
index++;
}

public synchronized int pop()
{
int retval;
if (index > 0)
{
retval = intArr[index-1];
index--;
return retval;
}
throw new EmptyStackException();
}
}


这个修改更改了实际上获取的锁。获取的锁是针对为其调用方法的对象的，而不是锁定 intArr 变量所引用的对象。因为获取的锁不再针对 intArr 所引用的对象，所以允许代码重新指定 intArr 对象引用。
Maximizing concurrency in Java programming
http://www-106.ibm.com/developerworks/ibm/library/it-haggar_concurrency/
Contents:
Avoid unnecessary synchronization
Use volatile to increase concurrency
Summary
Resources
About the author
Rate this article
Subscriptions:
dW newsletters
dW Subscription
(CDs and downloads)

Peter Haggar (haggar@us.ibm.com)
Senior Software Engineer , IBM
1 July 2001

When discussing concurrency, programmers typically look for ways to avoid its common problems. Concurrent access to data via multiple threads of execution, can cause stale, or invalid, reads and writes. In the Java programming language, the solution is to synchronize access to this data via the language's built-in synchronization mechanisms. The synchronized keyword is used to control access to shared data. However, synchronization ensures valid reads and writes of data at the cost of reduced concurrency. Because the Java language's synchronization mechanisms are not very granular, usage of it reduces the concurrency of your programs more than is sometimes needed. Less concurrency can result in poorly behaved and inefficient programs. This article outlines techniques to increase the concurrency of your code while maintaining its correctness. The first step to increasing concurrency is to avoid unnecessary synchronization.

Avoid unnecessary synchronization
The Java language provides synchronization to allow multiple threads of execution to access the same objects safely. Adding unneeded synchronization is as bad as omitting necessary synchronization. Sometimes programmers, in search of thread-safe code, synchronize too many methods. Excess synchronization can lead to code that deadlocks or code that runs slowly. (For more information on the cost of synchronization, see Praxis 34 of Practical Java Programming Language Guide and my last column on bytecode.) One goal of your software is to run efficiently, without deadlocks.

Because of the way the synchronized keyword is implemented, the result is often unnecessary synchronization and less concurrency. For example, consider the following class:

代码:

class Test {   private int[] ia1;   private int[] ia2;   private double[] da1;   private double[] da2;   public synchronized void method1()   {     //Access ia1 and ia2   }   public synchronized void method2()   {     //Access ia1 and ia2   }   public synchronized void method3()   {     //Access da1 and da2   }   public synchronized void method4()   {     //Access da1 and da2   }   //... }

This class is certainly thread safe. Each method must be declared synchronized in order to ensure the arrays are not corrupted by multiple threads accessing this object concurrently. For example, because method1 and method2 both access and potentially alter the arrays, ia1 and ia2 , access to them must be synchronized. The same is true of method3 and method4 .

Notice, however, that although method1 and method2 must be synchronized with each other, they do not need to be synchronized with either method3 or method4 . This is because method1 and method2 do not operate on data that method3 and method4 operate. This is also true for method3 and method4 with regard to method1 and method2 .

Unfortunately, this is how instance methods are sometimes synchronized in classes. Synchronization in the Java language is not very granular. Synchronization provides you with only one lock per object. In the previous code, if you create an object of class Test and call method1 on the main thread and method3 on a secondary thread, you pay an unnecessary performance penalty. These methods synchronize with one another even though there is no need for them to do so. Remember that when a method is declared synchronized , the lock obtained is the lock for the object on which the method is invoked. Therefore, both methods attempt to get the same lock.

To fix the problem in the previous code you need multiple locks per object. Because the Java language does not provide this, you must furnish your own mechanism. One way to accomplish this is to create objects as instance data that serve only to provide locks. The previous code is modified using this technique and looks like this:

代码:

class Test {   private int[] ia1;   private int[] ia2;   private double[] da1;   private double[] da2;   private byte[] lock1 = new byte[0];   private byte[] lock2 = new byte[0];   public void method1()   {    synchronized(lock1) {       //Access ia1 and ia2     }   }   public void method2()   {     synchronized(lock1) {       //Access ia1 and ia2     }   }   public void method3()   {     synchronized(lock2) {       //Access da1 and da2     }   }   public void method4()   {     synchronized(lock2) {       //Access da1 and da2     }   }   //... }

Notice that this code no longer has synchronized methods. They are removed and replaced with synchronized blocks. This allows the synchronization to occur on different objects and allows the methods that can safely run concurrently to do so. For example, method1 is able to execute concurrently with method3 or method4 because they access different object locks.

A zero element array is used as the lock objects because such an array is cheaper to create than any other object. Creating a zero element array does not require a constructor call like the creation of Object does. Therefore, it executes faster. In addition, a byte array is used because it is often represented more compactly than an int array.

Care must be taken when using this technique. You must be sure that the methods you think can operate without synchronization are able to do so without causing errors. Debugging multithreaded code can be very time consuming, so it is important not to use this technique casually.

You might wonder why method1 and method2 do not lock both ia1 and ia2 instead of the lock1 object. This could be done, but it is more error prone. When you lock multiple objects, you must make sure to lock them in the same order throughout your code. Failure to do this can result in deadlock. For more on this problem and how to avoid it, see Praxis 52 of Practical Java Programming Language Guide.

Use volatile to increase concurrency
When variables are shared between threads, they must always be accessed properly to ensure that correct and valid values are manipulated. The JVM is guaranteed to treat reads and writes of data of 32 bits or less as atomic. This might lead some programmers to believe that access to shared variables does not need to be synchronized or the variables declared volatile. Consider this code:

代码:

class RealTimeClock {   private int clkID;   private long clockTime;   public int clockID()   {     return clkID;   }   public void setClockID(int id)   {     clkID = id;   }   public long time()   {     return clockTime;   }   public void setTime(long t)   {     clockTime = t;   }   //... }

Now contemplate an implementation that uses the previous code. It might create an object of the RealTimeClock class and two threads. It could then call the methods of this class from the two threads.

The variables clkID and clockTime are stored in main memory. However, the Java language allows threads to keep private working copies of these variables. This enables a more efficient execution of the two threads. For example, when each thread reads and writes these variables, they can do so on the private working copies instead of accessing the variables from main memory. The private working copies are reconciled with main memory only at specific synchronization points.

The clockID and setClockID methods perform only a read and a write, respectively, on data of type int . Therefore, the operation of these methods is automatically atomic. However, given that the clkID variable could be stored in private working memory for each thread, consider the following possible sequence of events:

1. Thread 1 calls the setClockID method, passing a value of 5.
2. Thread 2 calls the setClockID method, passing a value of 10.
3. Thread 1 calls the clockID method, which returns the value 5.

This sequence of events is possible because the clkID variable is not guaranteed to be reconciled with main memory. During step 1, thread 1 places the value 5 in its working memory. When step 2 executes, thread 2 places the value 10 in its working memory. When step 3 executes, thread 1 reads the value from its working memory and returns 5. At no point are the values reconciled with main memory.

There are two ways to fix this problem.

1. Access the clkID variable from a synchronized method or block.
2. Declare the clkID variable volatile.

Either solution requires the clkID variable to be reconciled with main memory. Accessing the clkID variable from a synchronized method or block does not allow that code to execute concurrently, but it does guarantee that the clkID variable in main memory is updated appropriately. Main memory is updated when the object lock is obtained before the protected code executes and when the lock is released after the protected code executes.

Declaring the clkID variable volatile allows the code to execute concurrently and also guarantees that the private working copy of the clkID variable is reconciled with main memory. This reconciliation, however, occurs each time the variable is accessed.

Also consider the time and setTime methods that operate on a variable of type long. These methods can exhibit the same problem described previously. They also have an additional problem. Data of type long is typically represented by bits spread across two 32-bit words. An implementation of the JVM might treat the operation on a -bit value as atomic, but most JVM implementations today do not. Instead, it treats such operations as two distinct 32-bit operations. Consider the following possible sequence of events with the clockTime instance variable:

1. Thread 1 calls the time method.
2. Thread 1 begins to read the clockTime instance variable and reads the first 32 bits.
3. Thread 1 is preempted by thread 2.
4. Thread 2 calls the setTime method. The setTime method performs two writes of 32 bits each to the clockTime instance variable, replacing both 32-bit values with different values.
5. Thread 2 is preempted by thread 1.
6. Thread 1 reads the second 32 bits of the clockTime instance variable and returns the result.

Note: Implementations of JVMs are encouraged to treat -bit operations as atomic but are not required to do so. This is because some popular microprocessors currently do not provide efficient atomic memory transactions on -bit values.

According to this sequence of events, the value returned by the time method is made up of the first 32 bits of the old value of the clockTime instance variable and the second 32 bits of the new value of the same instance variable. The value returned is not correct. This is because of the multiple reads and writes necessary for -bit data in the JVM. The private working memory and main memory issue discussed earlier are also problematic. You have the same two options to fix this problem: Synchronize access to the clockTime variable, or declare it volatile.

It is important to understand that atomic operations do not automatically mean thread-safe operations. In addition, whenever multiple threads share variables, it is important that they are accessed in a synchronized method or block, or that they are declared with the volatile keyword. This ensures that the variables are properly reconciled with main memory, thereby guaranteeing correct values at all times.

Whether you use volatile or synchronized depends on several factors. If concurrency is important and you are not updating many variables, consider using volatile. If you are updating many variables, however, using volatile might be slower than using synchronization. Remember that when variables are declared volatile, they are reconciled with main memory on every access. By contrast, when synchronized is used, the variables are reconciled with main memory only when the lock is obtained and when the lock is released. Consider using synchronized if you are updating many variables and do not want the cost of reconciling each of them with main memory on every access, or you want to eliminate concurrency for another reason.

The following table summarizes the differences between the synchronized and volatile keywords.

volatile and synchronized

synchronized
Advantages: Private working memory is reconciled with main memory when the lock is obtained and when the lock is released.
Disadvantages : Eliminates concurrency.

volatile
Advantages: Allows concurrency.
Disadvantages: Private working memory is reconciled with main memory on each variable access.

Summary
This article demonstrates two techniques for increasing the concurrency of your program while maintaining its accuracy. The volatile keyword and distinct lock objects are used to increase concurrency while maintaining correctness. These techniques should be considered when designing and writing multithreaded code. The more concurrency in your program, the more likely it is to behave as the user expects it to.

Resources

* Practical Java Programming Language Guide, Peter Haggar, Addison-Wesley, 2000, ISBN 0-201-616-7.

* The Java Virtual Machine Specification, Second Edition, Tim Lindholm and Frank Yellin, Addison-Wesley, 1999, ISBN 0-201-43294-3.

About the author
Peter Haggar is a Senior Software Engineer with IBM in Research Triangle Park, North Carolina and the author of the book, Practical Java Programming Language Guide, published by Addison-Wesley. He has a broad range of programming experience, having worked on development tools, class libraries, and operating systems. At IBM, Peter works on emerging Java technology and is currently focused on embedded and real-time Java. Peter is a frequent technical speaker on Java technology at numerous industry conferences. He has worked for IBM for more than 12 years and received a B.S. in Computer Science from Clarkson University in New York. He can be contacted at haggar@us.ibm.com.
Synchronization and the Java Memory Model
http://gee.cs.oswego.edu/dl/cpj/jmm.html
This set of excerpts from section 2.2 includes the main discussions on how the Java Memory Model impacts concurrent programming.

For information about ongoing work on the memory model, see Bill Pugh's Java Memory Model pages.

Consider the tiny class, defined without any synchronization:

代码:

final class SetCheck {   private int  a = 0;   private long b = 0;   void set() {     a =  1;     b = -1;   }   boolean check() {     return ((b ==  0) ||             (b == -1 && a == 1));   } }

In a purely sequential language, the method check could never return false. This holds even though compilers, run-time systems, and hardware might process this code in a way that you might not intuitively expect. For example, any of the following might apply to the execution of method set:

* The compiler may rearrange the order of the statements, so b may be assigned before a. If the method is inlined, the compiler may further rearrange the orders with respect to yet other statements.
* The processor may rearrange the execution order of machine instructions corresponding to the statements, or even execute them at the same time.

* The memory system (as governed by cache control units) may rearrange the order in which writes are committed to memory cells corresponding to the variables. These writes may overlap with other computations and memory actions.

* The compiler, processor, and/or memory system may interleave the machine-level effects of the two statements. For example on a 32-bit machine, the high-order word of b may be written first, followed by the write to a, followed by the write to the low-order word of b.

* The compiler, processor, and/or memory system may cause the memory cells representing the variables not to be updated until sometime after (if ever) a subsequent check is called, but instead to maintain the corresponding values (for example in CPU registers) in such a way that the code still has the intended effect.

In a sequential language, none of this can matter so long as program execution obeys as-if-serial semantics. Sequential programs cannot depend on the internal processing details of statements within simple code blocks, so they are free to be manipulated in all these ways. This provides essential flexibility for compilers and machines. Exploitation of such opportunities (via pipelined superscalar CPUs, multilevel caches, load/store balancing, interprocedural register allocation, and so on) is responsible for a significant amount of the massive improvements in execution speed seen in computing over the past decade. The as-if-serial property of these manipulations shields sequential programmers from needing to know if or how they take place. Programmers who never create their own threads are almost never impacted by these issues.

Things are different in concurrent programming. Here, it is entirely possible for check to be called in one thread while set is being executed in another, in which case the check might be "spying" on the optimized execution of set. And if any of the above manipulations occur, it is possible for check to return false. For example, as detailed below, check could read a value for the long b that is neither 0 nor -1, but instead a half-written in-between value. Also, out-of-order execution of the statements in set may cause check to read b as -1 but then read a as still 0.

In other words, not only may concurrent executions be interleaved, but they may also be reordered and otherwise manipulated in an optimized form that bears little resemblance to their source code. As compiler and run-time technology matures and multiprocessors become more prevalent, such phenomena become more common. They can lead to surprising results for programmers with backgrounds in sequential programming (in other words, just about all programmers) who have never been exposed to the underlying execution properties of allegedly sequential code. This can be the source of subtle concurrent programming errors.

In almost all cases, there is an obvious, simple way to avoid contemplation of all the complexities arising in concurrent programs due to optimized execution mechanics: Use synchronization. For example, if both methods in class SetCheck are declared as synchronized, then you can be sure that no internal processing details can affect the intended outcome of this code.

But sometimes you cannot or do not want to use synchronization. Or perhaps you must reason about someone else's code that does not use it. In these cases you must rely on the minimal guarantees about resulting semantics spelled out by the Java Memory Model. This model allows the kinds of manipulations listed above, but bounds their potential effects on execution semantics and additionally points to some techniques programmers can use to control some aspects of these semantics (most of which are discussed in §2.4).

The Java Memory Model is part of The JavaTM Language Specification, described primarily in JLS chapter 17. Here, we discuss only the basic motivation, properties, and programming consequences of the model. The treatment here reflects a few clarifications and updates that are missing from the first edition of JLS.

The assumptions underlying the model can be viewed as an idealization of a standard SMP machine of the sort described in §1.2.4:

For purposes of the model, every thread can be thought of as running on a different CPU from any other thread. Even on multiprocessors, this is infrequent in practice, but the fact that this CPU-per-thread mapping is among the legal ways to implement threads accounts for some of the model's initially surprising properties. For example, because CPUs hold registers that cannot be directly accessed by other CPUs, the model must allow for cases in which one thread does not know about values being manipulated by another thread. However, the impact of the model is by no means restricted to multiprocessors. The actions of compilers and processors can lead to identical concerns even on single-CPU systems.

The model does not specifically address whether the kinds of execution tactics discussed above are performed by compilers, CPUs, cache controllers, or any other mechanism. It does not even discuss them in terms of classes, objects, and methods familiar to programmers. Instead, the model defines an abstract relation between threads and main memory. Every thread is defined to have a working memory (an abstraction of caches and registers) in which to store values. The model guarantees a few properties surrounding the interactions of instruction sequences corresponding to methods and memory cells corresponding to fields. Most rules are phrased in terms of when values must be transferred between the main memory and per-thread working memory. The rules address three intertwined issues:

Atomicity
Which instructions must have indivisible effects. For purposes of the model, these rules need to be stated only for simple reads and writes of memory cells representing fields - instance and static variables, also including array elements, but not including local variables inside methods.
Visibility
Under what conditions the effects of one thread are visible to another. The effects of interest here are writes to fields, as seen via reads of those fields.
Ordering
Under what conditions the effects of operations can appear out of order to any given thread. The main ordering issues surround reads and writes associated with sequences of assignment statements.

When synchronization is used consistently, each of these properties has a simple characterization: All changes made in one synchronized method or block are atomic and visible with respect to other synchronized methods and blocks employing the same lock, and processing of synchronized methods or blocks within any given thread is in program-specified order. Even though processing of statements within blocks may be out of order, this cannot matter to other threads employing synchronization.

When synchronization is not used or is used inconsistently, answers become more complex. The guarantees made by the memory model are weaker than most programmers intuitively expect, and are also weaker than those typically provided on any given JVM implementation. This imposes additional obligations on programmers attempting to ensure the object consistency relations that lie at the heart of exclusion practices: Objects must maintain invariants as seen by all threads that rely on them, not just by the thread performing any given state modification.

The most important rules and properties specified by the model are discussed below.

Atomicity
Accesses and updates to the memory cells corresponding to fields of any type except long or double are guaranteed to be atomic. This includes fields serving as references to other objects. Additionally, atomicity extends to volatile long and double. (Even though non-volatile longs and doubles are not guaranteed atomic, they are of course allowed to be.)

Atomicity guarantees ensure that when a non-long/double field is used in an expression, you will obtain either its initial value or some value that was written by some thread, but not some jumble of bits resulting from two or more threads both trying to write values at the same time. However, as seen below, atomicity alone does not guarantee that you will get the value most recently written by any thread. For this reason, atomicity guarantees per se normally have little impact on concurrent program design.

Visibility
Changes to fields made by one thread are guaranteed to be visible to other threads only under the following conditions:

* A writing thread releases a synchronization lock and a reading thread subsequently acquires that same synchronization lock.

In essence, releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields. While lock actions provide exclusion only for the operations performed within a synchronized method or block, these memory effects are defined to cover all fields used by the thread performing the action.

Note the double meaning of synchronized: it deals with locks that permit higher-level synchronization protocols, while at the same time dealing with the memory system (sometimes via low-level memory barrier machine instructions) to keep value representations in synch across threads. This reflects one way in which concurrent programming bears more similarity to distributed programming than to sequential programming. The latter sense of synchronized may be viewed as a mechanism by which a method running in one thread indicates that it is willing to send and/or receive changes to variables to and from methods running in other threads. From this point of view, using locks and passing messages might be seen merely as syntactic variants of each other.

* If a field is declared as volatile, any value written to it is flushed and made visible by the writer thread before the writer thread performs any further memory operation (i.e., for the purposes at hand it is flushed immediately). Reader threads must reload the values of volatile fields upon each access.

* The first time a thread accesses a field of an object, it sees either the initial value of the field or a value since written by some other thread.

Among other consequences, it is bad practice to make available the reference to an incompletely constructed object (see §2.1.2). It can also be risky to start new threads inside a constructor, especially in a class that may be subclassed. Thread.start has the same memory effects as a lock release by the thread calling start, followed by a lock acquire by the started thread. If a Runnable superclass invokes new Thread(this).start() before subclass constructors execute, then the object might not be fully initialized when the run method executes. Similarly, if you create and start a new thread T and then create an object X used by thread T, you cannot be sure that the fields of X will be visible to T unless you employ synchronization surrounding all references to object X. Or, when applicable, you can create X before starting T.

* As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see §4.3.2).

Note that visibility problems never arise when passing references to objects across methods in the same thread.

The memory model guarantees that, given the eventual occurrence of the above operations, a particular update to a particular field made by one thread will eventually be visible to another. But eventually can be an arbitrarily long time. Long stretches of code in threads that use no synchronization can be hopelessly out of synch with other threads with respect to values of fields. In particular, it is always wrong to write loops waiting for values written by other threads unless the fields are volatile or accessed via synchronization (see §3.2.6).

The model also allows inconsistent visibility in the absence of synchronization. For example, it is possible to obtain a fresh value for one field of an object, but a stale value for another. Similarly, it is possible to read a fresh, updated value of a reference variable, but a stale value of one of the fields of the object now being referenced.

However, the rules do not require visibility failures across threads, they merely allow these failures to occur. This is one aspect of the fact that not using synchronization in multithreaded code doesn't guarantee safety violations, it just allows them. On most current JVM implementations and platforms, even those employing multiple processors, detectable visibility failures rarely occur. The use of common caches across threads sharing a CPU, the lack of aggressive compiler-based optimizations, and the presence of strong cache consistency hardware often cause values to act as if they propagate immediately among threads. This makes testing for freedom from visibility-based errors impractical, since such errors might occur extremely rarely, or only on platforms you do not have access to, or only on those that have not even been built yet. These same comments apply to multithreaded safety failures more generally. Concurrent programs that do not use synchronization fail for many reasons, including memory consistency problems.

Ordering
Ordering rules fall under two cases, within-thread and between-thread:

* From the point of view of the thread performing the actions in a method, instructions proceed in the normal as-if-serial manner that applies in sequential programming languages.

* From the point of view of other threads that might be "spying" on this thread by concurrently running unsynchronized methods, almost anything can happen. The only useful constraint is that the relative orderings of synchronized methods and blocks, as well as operations on volatile fields, are always preserved.

Again, these are only the minimal guaranteed properties. In any given program or platform, you may find stricter orderings. But you cannot rely on them, and you may find it difficult to test for code that would fail on JVM implementations that have different properties but still conform to the rules.

Note that the within-thread point of view is implicitly adopted in all other discussions of semantics in JLS. For example, arithmetic expression evaluation is performed in left-to-right order (JLS section 15.6) as viewed by the thread performing the operations, but not necessarily as viewed by other threads.

The within-thread as-if-serial property is helpful only when only one thread at a time is manipulating variables, due to synchronization, structural exclusion, or pure chance. When multiple threads are all running unsynchronized code that reads and writes common fields, then arbitrary interleavings, atomicity failures, race conditions, and visibility failures may result in execution patterns that make the notion of as-if-serial just about meaningless with respect to any given thread.

Even though JLS addresses some particular legal and illegal reorderings that can occur, interactions with these other issues reduce practical guarantees to saying that the results may reflect just about any possible interleaving of just about any possible reordering. So there is no point in trying to reason about the ordering properties of such code.

Volatile
In terms of atomicity, visibility, and ordering, declaring a field as volatile is nearly identical in effect to using a little fully synchronized class protecting only that field via get/set methods, as in:

代码:

final class VFloat {   private float value;   final synchronized void  set(float f) { value = f; }   final synchronized float get()        { return value; } }

Declaring a field as volatile differs only in that no locking is involved. In particular, composite read/write operations such as the "++'' operation on volatile variables are not performed atomically.

Also, ordering and visibility effects surround only the single access or update to the volatile field itself. Declaring a reference field as volatile does not ensure visibility of non-volatile fields that are accessed via this reference. Similarly, declaring an array field as volatile does not ensure visibility of its elements. Volatility cannot be manually propagated for arrays because array elements themselves cannot be declared as volatile.

Because no locking is involved, declaring fields as volatile is likely to be cheaper than using synchronization, or at least no more expensive. However, if volatile fields are accessed frequently inside methods, their use is likely to lead to slower performance than would locking the entire methods.

Declaring fields as volatile can be useful when you do not need locking for any other reason, yet values must be accurately accessible across multiple threads. This may occur when:

* The field need not obey any invariants with respect to others.

* Writes to the field do not depend on its current value.

* No thread ever writes an illegal value with respect to intended semantics.
* The actions of readers do not depend on values of other non-volatile fields.

Using volatile fields can make sense when it is somehow known that only one thread can change a field, but many other threads are allowed to read it at any time. For example, a Thermometer class might declare its temperature field as volatile. As discussed in §3.4.2, a volatile can be useful as a completion flag. Additional examples are illustrated in §4.4, where the use of lightweight executable frameworks automates some aspects of synchronization, but volatile declarations are needed to ensure that result field values are visible across tasks.

JUnit

JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。

http://www.junit.org/

【Java开源 Java测试工具】

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=568616

• LoginServletTest.java

package onlyfun.caterpillar.test;

import junit.framework.Test;
import junit.framework.TestSuite;

import org.apache.cactus.ServletTestCase;
import org.apache.cactus.WebRequest;
import org.apache.cactus.extension.jetty.JettyTestSetup;

import onlyfun.caterpillar.LoginServlet;

public class LoginServletTest extends ServletTestCase {
    public static Test suite() {
        System.setProperty("cactus.contextURL", 
                      "http://localhost:8080/cactusDemo");
        TestSuite suite = new TestSuite();
        suite.addTestSuite(LoginServletTest.class);
        return new JettyTestSetup(suite);
    }

    public void beginValidUser(WebRequest webRequest) {
        webRequest.addParameter("username", "justin");
        webRequest.addParameter("password", "123456");
    }

    public void testValidUser() {
        LoginServlet loginServlet = new LoginServlet();
        assertTrue(loginServlet.isValidUser(request));
    }

    public void beginInValidUser(WebRequest webRequest) {
        webRequest.addParameter("username", "guest");
        webRequest.addParameter("password", "123456");
    }

    public void testInValidUser() {
        LoginServlet loginServlet = new LoginServlet();
        assertFalse(loginServlet.isValidUser(request));
    }

    public static void main(String[] args) { 
        junit.textui.TestRunner.run(
                   LoginServletTest.suite()); 
    } 
}

• LoginServlet.java

package onlyfun.caterpillar;

import javax.servlet.http.*;

public class LoginServlet extends HttpServlet {
    public boolean isValidUser(HttpServletRequest request) {
        String username = request.getParameter("username");
        String password = request.getParameter("password");

       if(username == null || 
          password == null ||
          !username.equals("justin") || 
          !password.equals("123456")) {
            return false;
        }
        else {
            return true;
        }
    }
}

(如今的程序领域，大家都在说，面向对象OOP,但是真正能理解面向对象的含义的程序员却很少，究竟什么是对象，怎样面向对象)
一．面向对象：
1.何谓对象：在面向对象程序设计中，我们将问题空间中的元素以及他们在方案空间中的的表示物称作对象（object）
 Alan Kay总结了smalltalk中对象的5大基本特征：
所有的东西都是对象。
程序是一大堆对象的集合，他们通过消息传递，各个对象之间知道要做些什么。
每个对象都分配有自己的存储空间，可容纳其他对象。
每个对象都有一个类型。
同一类的所有对象能接收相同的消息。
 -----而所有的编程语言的最终目的是提供一种抽象方法----
2．对象的接口：我们向对象发出请求是通过它的接口定义的，对象的类型决定了它的接口形式。
3．OOP中唯一关心的： 就是接口是什么，就像汽车的发动机一样，我们不必要知道它的结构是什么，只要它能工作就行了。所有的程序是由一定的属性（数据）和行为（方法）组成的，不同的对象访问通过函数调用来完成，对象间的所有交流都是通过方法调用，通过对封装数据对象，很大程度上提高复用率。
4．对象的3个主要特征：
      behavior—说明这个对象能做什么。
      State—当对象施加方法时对象的反映。
      Identity---与其他相似行为对象的区分标志，每一个对象有唯一的indentity, 而这3者是相互影响的。
5．面向对象中最重要的思想 就是类，类是模板是蓝图，从类中构造一个对象，即创建了一个类的实例。（类好比一个建材市场，其中有许多子类--各种各样的装饰材料，而我们装修自己的房子就要选择我们需要的材料，（为了建立我们自己的程序，我们必须选 择我们需要的类）这个比喻可以很形象的解释类是什么。
6．类之间的关系：
        依赖关系：use-a  A类中的一个方法操作了另一个类中的对象。
        聚合关系：has-a  A类中的对象包含B类的对象。
        继承关系：is-a   A继承了B类，此时A类不仅有了B类的方法，还加入了自己的方法。以便我们创建我们自己需要的对象。
Java中定义的每一个类都必须继承另一个类，使用关键字extends，如果一个类在定义中不现实使用关键字extends,这个类就会隐式继承Object类。Object类又叫根超类，或基类。，我们从根超类继承来的叫子类。Java中每个类都是根超类的子类。

8．接口（interface）规定了可对特定的对象发出哪些请求。
9．继承=重新使用接口：创建出一个数据类型后，当需要新建立一个数据类型去实现相同的功能，是很没有意义的一件事，此时对其克隆后，再根据情况改进实现自己的目的就是继承。

10．封装：就是把数据和行为结合在一起在一个包中，并对对象使用者隐藏数据的实现过程。Java用3个关键字来设置边界，从而进行对数据的隐藏。Public(共有)的定义任何人都可使用.private（私有）意味着除你自己，类型创建者及那个类型的内部函数成员可以访问外其他任何人使用都会产生错误。Friendly（友好）
意味在包(package)中是可以访问的。（以上过程也可叫方案隐藏）
11．引用（Handle）操控对象：
    当创建一个引用时必须要对其进行初始化
  例: String s=”happy”（未建立连接）
     String s=new string(“happy”)与一个新的对象连接使用new 。此句建立了一个引用，并且连接引用并初始化对象 赋值字符串“happy”.
12.对象的创建及存在时间：数据存放的地点
       1：寄存器-速度快，数量少，在cpu内部，我们对寄存器没有控制权。
       2：堆栈：驻留长规内存中，堆栈指针下移建立新的内存，上移释放内存。
      3：堆：常用内存池，保存对象，有极大的灵活性，java的数据就存放在此，但是要以时间及效率为代价。Java的对象建立是在程序运行时才决定。而c++是在设计时建立对象。
 对象的生存时间（lifetime）java提出的垃圾收集器可以很好的发现无须再用的对象，使用GC（grabage collector）垃圾收集器。清除对象，释放内存。
为此我们就要付出一定的运行期的开销。
13.在此我们就会有这样一个印象,一个程序只是一系列对象的集合,他们的方法将其他对象作为自己的变量使用.
14.主要类型: java的主要类型有:boolean,char,byte,short,int,long,float,double,void.这些主类型的大小都不随机器的结构变化而变化,提供了java很好的可移植性.
15.字段方法:字段又叫数据成员,成员函数又叫方法,java的全部工作就是定义类,制作累得对象及发送消息.
16.一个程序只是一系列对象的集合,他们的方法将其他的对象作为自己的变量使用,而且将消息发给那些对象.
17.名字的可见性:为了使名字不重复,作者可以定义自己的库,一般用自己域名的倒写形式 如: COM.:Leeak.utility.foidles
18.static关键字:即使没有创建对象,也需要一愕能调用的方法,此时可以使用static
19.java.lang默认自动的导入每个java程序中
20.OOP中对象使对属性和方法的封装,对象具有信息的隐蔽的性质,对细节的隐藏,对象只需要知道去这样做,而不知道如何做的细节,类的方法应谨慎控制对java数据的访问,可以用get读取方法,用set修改方法.

21:pakage:Java API中每个类和接口属于一个特定的包,包实际上市对类和接口进行组织的目录结构,提供了一种软件复用机制.
22.创建可复用的类得步骤:1.定义一个public类
                                               2.选择一个包名,并把pakage语句加到可复用的类的源码中.
                           3.编译这个类.
4.把可复用的类导入其他程序中即可.
23.java中提出在类定义的括号外的仅有2个语句,pakage和import.
24.软件的复用性,软件的复用性就是利用紫的已有的,定义良好的的经过仔细测试的文档清晰的可移植的易于获得的软件构件开发新的软件.

以上就是java面向对象的一些基本术语的概述,其中的有些部分可以扩展的更深,看过think in java的 朋友就会有此种感觉.此文章向对初学者阐述了面向对象的基本概念.对已是java程序员的朋友可以对他们的基本知识做以回顾.

http://www.csdn.net/Develop/article/22/22198.shtm

function dbClass(){
$this->conn = mysql_connect("$this->hostName","$this->Login","$this->Password");
mysql_select_db("$this->dbName", $this->conn);
}

function executeQuery($sql){
$this->result = mysql_query("$sql",$this->conn);
return $this->result;
}

function closeConn(){
mysql_close($this->conn);
}
}

?>

2.解决分页问题的PageQuery.inc
<?php
include("dbClass.inc");
class PageQuery extends dbClass {
    private $Offset;             // 记录偏移量
    private $Total;             // 记录总数
     
    private $maxLine;             // 记录每页显示记录数
    private $result;             // 读出的结果
   
    private $TPages;             // 总页数
    private $CPages;             // 当前页数
   
    private $PageQuery;         // 分页显示要传递的参数
    private $Query;             // query 语句
    private $QueryPart;         // " FROM " 以后的 query 部分
    private $QueryString;         // ? 以后部分 
     
    private $FilePath;
           
    // 每页显示行数
    function PageQuery($pageLine=10) {   
        $this->dbClass();
        $this->maxLine = $pageLine;
      }
     
      // 记录总数
    function getTotal(){
        return $this->Total;
    }
     
      // 显示总页数
    function getTotalPages() {
        return $this->TPages;
    }

    //显示当前所在页数
    function getCurrenPages() {         
        return $this->CPages;
    }
   
    function myQuery($sql, $flag=1){
            GLOBAL $offset;
            $this->Query = $sql;
       
        // 获取文件名
        //$this->FilePath = $GLOBALS["REQUEST_URI"];
            $this->FilePath = $GLOBALS["SCRIPT_NAME"];
           
            // 获取查询条件
            $this->QueryString = $GLOBALS["QUERY_STRING"];           
            //echo $this->QueryString . "<br>";           
           
            // 截取 " from " 以后的 query 语句
            $this->QueryPart = trim(strstr($sql, " from "));
           
            // 计算偏移量
            if (!isset($offset)) $this->Offset = 0;
            else $this->Offset = (int)$offset;
           
           
       
       
        // 计算总的记录条数
        $SQL = "SELECT Count(*) AS total " . $this->QueryPart;
        $this->result = $this->executeQuery($SQL);
            $this->Total = mysql_result($this->result,0);
           
            // 设置当前页数和总页数
        $this->TPages = (double)Ceil((double)$this->Total/$this->maxLine);
        $this->CPages = (double)Floor((double)$this->Offset/$this->maxLine+1);
       
       
        // 根据条件判断，取出所需记录
        if ($this->Total > 0) {
            //flag等于1表示要分页，否则不分页
            if($flag==1)
                $SQL = $this->Query . " LIMIT " . $this->Offset . " , " . $this->maxLine;
            else
                $SQL = $this->Query;           
            echo $SQL . "<br>";
            $this->result = $this->executeQuery($SQL);
        }
        return $this->result;
    }
   
    //**********显示翻页提示栏************* 
    // 显示首页、下页、上页、尾页
    function PageLegend() {       
     $str = "";
        $i = 0;
        $first = 0;
        $next = 0;
        $prev = 0;
        $last = 0;
   
            $next = $this->Offset + $this->maxLine;
            $prev = $this->Offset - $this->maxLine;
            $last = ($this->TPages - 1) * $this->maxLine;
           
            GLOBAL $offset;
            if (!isset($offset)) $this->QueryString .= "&offset=";
            else{
                $this->QueryString = substr($this->QueryString,0,strrpos($this->QueryString,'&')) . "&offset=";
            }
           
            if($this->Offset >= $this->maxLine)
            $str .=  " <A href=" . $this->FilePath . "?" . $this->QueryString . $first . ">首页</A> ";
            else $str .= " 首页 ";
       
        if($prev >= 0)
            $str .=  " <A href=" . $this->FilePath . "?" . $this->QueryString . $prev . ">上一页</A> ";
        else $str .= " 上一页 ";
       
        if($next < $this->Total)
            $str .=  " <A href=" . $this->FilePath . "?" . $this->QueryString . $next . ">下一页</A> ";
        else $str .= " 下一页 ";
       
        if($this->TPages != 0 && $this->CPages < $this->TPages)
            $str .=  " <A href=" . $this->FilePath . "?" . $this->QueryString . $last . ">尾页</A>";
        else $str .= " 尾页 ";

        $str .= " 页次：" . $this->getCurrenPages() . "/" . $this->getTotalPages() . "页 ";
        $str .= $this->maxLine . "条/页 " . "共" . $this->Total . "条";
            return $str;
    }
}
?>
3.用于显示结果的mysql_result_all.inc
<?
function mysql_result_all($result,$format="") {
echo "<table $format><tr>";
for($i=0;$i<mysql_num_fields($result);$i++) {
echo "<th>".mysql_field_name($result,$i)."</th>";
}
echo "</tr>";
while($row = mysql_fetch_array($result) ) {
for($i=0;$i<mysql_num_fields($result);$i++) {
echo "<td>".$row[$i]."</td>";
}
echo "</tr>";
}
echo "</table>";
}
?>
4.显示页面的代码：
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>php＆mysql分页显示</title>
</head>

<body>
<?php
include("PageQuery.inc");

$pq = new PageQuery(5); // 获取Connection
$res=$pq->myQuery("select * from users"); // 执行查询

require("mysql_result_all.inc");
mysql_result_all($res,"border=1");
echo $pq->PageLegend(2); // 翻页栏
?>
</body>
</html>