SessionFactory是线程安全的,Session是非线程安全的，如何正确理解?
去看了SessionFactoryImpl的源码。里面的实例变量大部分是final类型的，不可改变。但是有两个transient类型非final的。

再看SessionImpl的源码。大部分的实例变量是transient非final类型的。但是有一个

private EntityNameResolver entityNameResolver = new CoordinatingEntityNameResolver();

这如何解释实例变量影响线程安全呢？

Java code

public final class SessionFactoryImpl implements SessionFactory, SessionFactoryImplementor {    private static final Logger log = LoggerFactory.getLogger(SessionFactoryImpl.class);    private static final IdentifierGenerator UUID_GENERATOR = new UUIDHexGenerator();    private final String name;    private final String uuid;    private final transient Map entityPersisters;    private final transient Map classMetadata;    private final transient Map collectionPersisters;    private final transient Map collectionMetadata;    private final transient Map collectionRolesByEntityParticipant;    private final transient Map identifierGenerators;    private final transient Map namedQueries;    private final transient Map namedSqlQueries;    private final transient Map sqlResultSetMappings;    private final transient Map filters;    private final transient Map imports;    private final transient Interceptor interceptor;    private final transient Settings settings;    private final transient Properties properties;    private transient SchemaExport schemaExport;    private final transient TransactionManager transactionManager;    private final transient QueryCache queryCache;    private final transient UpdateTimestampsCache updateTimestampsCache;    private final transient Map queryCaches;    private final transient Map allCacheRegions = new HashMap();    private final transient StatisticsImpl statistics = new StatisticsImpl(this);    private final transient EventListeners eventListeners;    private final transient CurrentSessionContext currentSessionContext;    private final transient EntityNotFoundDelegate entityNotFoundDelegate;    private final transient SQLFunctionRegistry sqlFunctionRegistry;    private final transient SessionFactoryObserver observer;    private final transient HashMap entityNameResolvers = new HashMap();    private final QueryPlanCache queryPlanCache = new QueryPlanCache( this );    private transient boolean isClosed = false;

Java code

public final class SessionImpl extends AbstractSessionImpl        implements EventSource, org.hibernate.classic.Session, JDBCContext.Context {    // todo : need to find a clean way to handle the "event source" role    // a seperate classs responsible for generating/dispatching events just duplicates most of the Session methods...    // passing around seperate reto interceptor, factory, actionQueue, and persistentContext is not manageable...    private static final Logger log = LoggerFactory.getLogger(SessionImpl.class);    private transient EntityMode entityMode = EntityMode.POJO;    private transient boolean autoClear; //for EJB3        private transient long timestamp;    private transient FlushMode flushMode = FlushMode.AUTO;    private transient CacheMode cacheMode = CacheMode.NORMAL;    private transient Interceptor interceptor;    private transient int dontFlushFromFind = 0;    private transient ActionQueue actionQueue;    private transient StatefulPersistenceContext persistenceContext;    private transient JDBCContext jdbcContext;    private transient EventListeners listeners;    private transient boolean flushBeforeCompletionEnabled;    private transient boolean autoCloseSessionEnabled;    private transient ConnectionReleaseMode connectionReleaseMode;        private transient String fetchProfile;    private transient Map enabledFilters = new HashMap();    private transient Session rootSession;    private transient Map childSessionsByEntityMode;    private EntityNameResolver entityNameResolver = new CoordinatingEntityNameResolver(); 
 

[解决办法]
Session session = SessionFactory.getSession();
这一步加final的意思是session这个引用对象只能指向SessionFactort.getSession()传回的这个对象，之后其指向的对象地址不能再次改变，不加final是可以再次赋值（即再次改变其指向）的。而加不加final，session所指向的这个对象的内在属性是完全可以改变的，甚至可以模拟两个线程，同时调用其方法，改变这个对象的设置。所以加final与线程安全与否几乎没有关系。
方法中的局部变量会随着方法的调用而新建和释放，因此没有线程安全之忧，有担忧的确是是类变量，不过这也要看情况。类的实例对象在正常使用的情况下也不存在线程问题（不同线程不同对象），但某些情况就会有问题，比如servletClass的实例，请求第一次到达后web容器会实例化对应的servletClass，而此后无论再有多少类似请求，都会使用第一次实例化的这个对象（除非长期没有这个请求，web容器有可能会销毁这个对象）而http请求是有并发现象存在的，操作的又是同一个对象，当然会出现并发操作同一个对象中的同一个类变量的问题，这就是线程不安全的一个例子。
SessionFactory在方法中创建Session，并返回给调用端，当然不存在线程问题，当然能保证为不同地点，不同线程的调用者提供不同的Session，而Session一旦创建，就要看调用者如何使用了，把它当做类变量使用，而又把这个类的实例供多个线程操作，而又不加排它锁，当然会出线程安全的问题。通常在控制单元（servletClass/struts的action）使用hibernateSession或jdbc的connection时，都不建议把它作为类变量来用。
------------------
打的累死了，呼呼，发现自己越来越嗦了，但愿是楼主要的答案。

[解决办法]
首先，我认为你的核心问题是这个：
“在不使用ThreadLocal维护session的情况下。为什么说Session是非线程安全的。是否是因为它存在很多类级变量吗？如果确实如此的话，那么SessionFactory尽管是是线程安全的。但它同样也存在很多类级的非final成员实例变量,如：private transient boolean isClosed = false;private transient SchemaExport schemaExport;这难道不会影响线程安全么?”

这个问题应该从两个角度说：
首先，我认为楼主需要弄清楚的是final关键字可以修饰多种目标，final可以修饰非抽象类、非抽象类成员方法和变量。
如果是修饰类，那么final类不能被继承，没有子类，final类中的方法默认是final的。
如果是修饰方法，那么final方法不能被子类的方法覆盖，但可以被继承。
如果是修饰成员变量，那么final成员变量表示常量，只能被赋值一次，赋值后值不再改变。
另外，final不能用于修饰构造方法。
由此可见，SF（SessionFactory）中的确已经将绝大部分的成员变量设计成了final的，因此，确实不存在并发冲突的问题，而对仅有的几个非final成员变量的操作也并非在SF类中提供，因此，SF确实是现成安全的。反观Session,transient是和序列化相关的一个修饰符，和线程安全无关，因此，Session中的大部分成员变量都复发避免并非访问冲突的可能。因此，Session确实不能认为是线程安全的。

其次，线程安全和线程敏感这两个概念我个人认为应该区分一下，ThreadLocal实现的只是一种线程敏感特性，也就是说，Hibernate2中需要用Util包中的方法获得和线程相关的Session，而到了Hibernate3,尽管SessionFactory中已经整合好了ThreadLocal的特性，这主要是依靠CurrentSessionContext接口的不同实现类（如JPA，Hibernate等实现模式）来从一个大的SessionMap中获得和线程相关的Session(这种Session一般称为线程敏感的)，但是，Session自身依然是非线程安全的，原因见前面“首先”部分的分析。这里引入“其次”的分析主要是想避免将线程安全和线程敏感混淆。

最后，10楼的哥们第一段和最后一段说的很多，第一段中说的final的位置楼主不要认为是修饰成员变量，他说的final的位置是修饰整个实例对象，这个时候由于实例对象属于引用对象，因此考虑到堆内存和栈内存的关系，实际对象依然可以被不同线程改变，因此，在实例对象前加final修饰符并不能代表这个对象就是线程安全的。
10楼的最后一段说的也很好，其实之所以说要认识到Session是非线程安全的，主要是提醒大家，在自己开发的调用类中，不要将Session设置为成员变量，而是要将Session写在方法中，这样得到的Session才是因线程而异的，如果放在类中，只随着Servlet初始化时构建一次，那么今后并发冲突时肯定难免的了。

打了这么多，还挺累的。。。
[解决办法]
SessionFactoryImpl 显然不是严格语义上的thread safe,那么多getXXX()都暴露在外面，客户程序可以随意put。
为什么java doc里面说的“It is crucial that the class is not only thread safe, but also highly concurrent.” ？
那是因为有些变量虽然可以改，但是不会影响功能，因为在constructor的时候变量已经从Configuration里面解析好了，譬如：SessionFactoryImpl.setting。
再者有些变量已经处理过了，你get了也没法改。譬如：SessionFactoryImpl.classMetadata，在constructor的时候已经classMetadata = Collections.unmodifiableMap(classMeta);了。

[解决办法]
isClose()确实被SF实现类提供，是暴露的，但是，不是说一个类暴露了变量，那么这个类就一定是不安全的，这里所谓的安全主要是指是否能有效控制并发。而所谓并发控制首先需要明确的是边界，并发控制的边界我认为是："从你执行‘读’到你执行‘写’这一过程中有没有其它的人‘写入’？" 由于SF的open与close基本上是托管给容器的，因此这个变量的状态不是一个线程可以改变的，所以，这样的变量并不涉及并发冲突。因此也不影响线程安全。
另外，并发控制一般靠锁来实现，他的核心思想是解决‘读’完之后谁能‘写’，而事物隔离级别解决的是‘写’完之后谁能‘读’。他们分别体现的是ACID中的C和I，是不同的概念。有没有其它的人写？”
综上，一个暴露的变量如果从功能设计上的目的只是为了提供‘读取’的目的，那么即使暴露也不会产生任何预期的并发冲突。
这几天忙着去北京申请访问学者的签证，所以没有来回帖，不好意思。