HttpSession
HttpSession:是一个抽象接口,J2EE的Web程序在运行的时候,会给每一个新的访问者建立一个HttpSession,这个Session是用户身份的唯一标示,WEB 会话跟踪用的。【注:是容器(Tomca)自动创建的】
HttpSession用途:存放用户的一些经常被用到的信息,如:用户名,权限。
HttpSession获取方法:HttpSession session = request.getSession();
Hibernate Session
Hibernate Session是把JDBC的Connection和Transaction接口进行了简单的封装后的一个接口,即此Session主要用来管理对象的增、删、改、查和事务的,还有只要持久化类的实例对象与Session关联了,那此对象就不只是简单的在内存中了,而是可以通过Session对象去管理它了,所以也称此对象在Session缓存中即Hibernate所提到的一级缓存。
public class MyTest { public static void main(String[] args) throws Exception { new TestThread().start(); new TestThread().start(); Thread.sleep(1000); System.out.println("Doing something..."); synchronized (lock) { lock = false; // 语句1 lock.notifyAll(); // 语句2 } } static volatile Boolean lock = true; } class TestThread extends Thread { @Override public void run() { synchronized (MyTest.lock) { while (MyTest.lock) { try { MyTest.lock.wait(); } catch (InterruptedException e) { e.printStackTrace(); } } System.out.println(getId()); } } }输出结果为
synchronized (lock) { lock = false; // 语句1 lock.notifyAll(); // 语句2 }
语句1那里修改了lock的对象指向,结果造成下面的一句notifyAll使用了一个并没有synchronized的对象,随意报出了异常。
解决方法
方案1,使用Boolean的特殊性 由于 lock=false;的特殊性,分析Boolean的源代码发现
public static final Boolean TRUE = new Boolean(true); public static final Boolean FALSE = new Boolean(false); public static Boolean valueOf(boolean b) { return (b ? TRUE : FALSE); } //发现其内部对于自动打包,拆包只使用了2个固定的对象。所以可以用 synchronized (lock) { lock = false; // 语句1 Boolean.TRUE.notifyAll(); // 语句2 } // 直接使用那个TRUE就行了。
方法2:使用一个参数可变对象,而不是不可变的,
比如
class MyLock { boolean lock = true; }
static volatile MyLock lock = new MyLock();
// 然后再代码里面用
lock.lock=false;// 进行标志的变更和判断就可以了
结论:
同步锁最好单独使用,如果锁自身附带了其它作用,应使用一个可变的对象 推荐
static volatile MyLock lock = new MyLock();
应该写成:
final static volatile MyLock lock = new MyLock();注意:volatile修饰符
Volatile修饰的成员变量在每次被线程访问时,都强迫从共享内存中重读该成员变量的值。而且,当成员变量发生变化时,强迫线程将变化值回写到共享内存。这样在任何时刻,两个不同的线程总是看到某个成员变量的同一个值。 Java语言规范中指出:为了获得最佳速度,允许线程保存共享成员变量的私有拷贝,而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。 这样当多个线程同时与某个对象交互时,就必须要注意到要让线程及时的得到共享成员变量的变化。 而volatile关键字就是提示VM:对于这个成员变量不能保存它的私有拷贝,而应直接与共享成员变量交互。
使用建议:在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中,或者为常量时,不必使用。 由于使用volatile屏蔽掉了VM中必要的代码优化,所以在效率上比较低,因此一定在必要时才使用此关键字。
一、活锁 如果事务T1封锁了数据R,事务T2又请求封锁R,于是T2等待。T3也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待。然后T4又请求封锁R,当T3释放了R上的封锁之后系统又批准了T4的请求,...,T2有可能永远等待,这就是活锁的情形,如图8.4(a)所示。 避免活锁的简单方法是采用先来先服务的策略。 二、死锁 如果事务T1封锁了数据R1,T2封锁了数据R2,然后T1又请求封锁R2,因T2已封锁了R2,于是T1等待T2释放R2上的锁。接着T2又申请封锁R1,因T1已封锁了R1,T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2,而T2又在等待T1的局面,T1和T2两个事务永远不能结束,形成死锁。