Session是以Cookie技术或URL重写实现。默认以Cookie技术实现，服务端会给这次会话创造一个JSESSIONID的值。
这个id值会发送给client，client每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在client会保存下来，保存的容器就是cookie。protected Session doGetSession(boolean create) { // There cannot be a session if no context has been assigned yet if (context == null) return (null); // Return the current session if it exists and is valid if ((session != null) && !session.isValid()) session = null; if (session != null) return (session); // Return the requested session if it exists and is valid Manager manager = null; if (context != null) manager = context.getManager(); if (manager == null) return (null); // Sessions are not supported if (requestedSessionId != null) { try { session = manager.findSession(requestedSessionId); } catch (IOException e) { session = null; } if ((session != null) && !session.isValid()) session = null; if (session != null) { session.access(); return (session); } } // Create a new session if requested and the response is not committed if (!create) return (null); if ((context != null) && (response != null) && context.getCookies() && response.getResponse().isCommitted()) { throw new IllegalStateException (sm.getString("coyoteRequest.sessionCreateCommitted")); } // Attempt to reuse session id if one was submitted in a cookie // Do not reuse the session id if it is from a URL, to prevent possible // phishing attacks if (connector.getEmptySessionPath() && isRequestedSessionIdFromCookie()) { session = manager.createSession(getRequestedSessionId()); } else { session = manager.createSession(null); } // Creating a new session cookie based on that session if ((session != null) && (getContext() != null) && getContext().getCookies()) { String scName = context.getSessionCookieName(); if (scName == null) { scName = Globals.SESSION_COOKIE_NAME; } Cookie cookie = new Cookie(scName, session.getIdInternal()); configureSessionCookie(cookie); response.addSessionCookieInternal(cookie, context.getUseHttpOnly()); } if (session != null) { session.access(); return (session); } else { return (null); } }
上面代码就是依据 requestedSessionId 去查找session，找不到就创建新的session。那么 requestedSessionId 怎么获取的呢？
Request详细的逻辑是调用Context容器的getManger方法获取Session管理器（session管理器详情下文介绍），然后假设SessionId假设已经被解析出来了。那么则会调用findSession方法从session对象池中获取相应的session，反之假设sessionId不存在，则须要又一次创建一个Session，并放入session对象池中。
类RequestFacade的getSession方法：
实现包的路径是： org.apache.catalina.session ，tomcat对外提供session调用的接口不在这个实现包里。对外接口是在包 javax.servlet.http 下的 HttpSession。 而实现包里的 StandardSession 是tomcat提供的标准实现，当然对外tomcat不希望用户直接操作 StandardSession ，而是提供了一个 StandardSessionFacade 类，tomcat容器里详细操作session的组件是servlet。而servlet操作session是通过 StandardSessionFacade 进行的。这样就能够防止程序猿直接操作 StandardSession 所带来的安全问题。 
(1) Manager：定义了关联到某一个容器的用来管理session池的基本接口。这是catalina包下的。
(2) ManagerBase：实现了Manager接口。该类提供了Session管理器的常见功能的实现。
(3) StandardManager：继承自ManagerBase,tomcat的默认Session管理器（不指定配置，默认使用这个），是tomcat处理session的非集群实现（也就说是单机版的），tomcat关闭时，内存session信息会持久化到磁盘保存为SESSION.ser,再次启动时恢复。
(4) PersistentManagerBase：继承自ManagerBase，实现了和定义了session管理器持久化的基础功能。
(5) PersistentManager：继承自PersistentManagerBase，主要实现的功能是会把空暇的会话对象（通过设定超时时间）交换到磁盘上。
(6)StoreBase:存放持久化有关store接口的基本实现。
接口Store及事实上例是为session管理器提供了一套存储策略。store定义了主要的接口。而StoreBase提供了主要的实现。
当中FileStore类实现的策略是将session存储在以setDirectory（）指定文件夹并以.session结尾的文件里的。JDBCStore类是将Session通过JDBC存入数据库中，因此须要使用JDBCStore，须要分别调用setDriverName()方法和setConnectionURL()方法来设置驱动程序名称和连接URL。
(7) StandardSession :tomcat的session实现类。
2.4 Tomcat session相关的配置
从两个层面总结一下session相关的配置和设置。首先是从配置文件层面，session是有过期时间的，这个默认的过期时间是 在$catalina_home/conf/web.xml有定义的。详细的默认配置例如以下（默认的过期时间是30min，即30min没有訪 问，session就过期了）：
另一点就是session管理假设不配置就默认使用StandardManager。但假设要配置的话能够 在$catalina_home/conf/context.xml当中指定（当中从这个配置当中能够看到session管理器是和context容器关 联的，也就说每一个web应用都会有一个session管理器）详细的配置例如以下：
Tomcat7.x默认这个manager的配置是凝视掉的。假设要指定的PersistentManager为默认管理器的话能够这么指定：
事实上看到这也就发现了，事实上session管理器或者Store存储策略。仅仅要实现了相关的接口，都是能够自己定义的。
自己写一个配置在这里就ok了。
另外在从代码层面总结一下：session的一些配置信息是写死在代码里的，比方SessionConfig这个类就定义了一些session的设 置信息。Session在cookie中的名字是JSESSION. Session通过URL重写的方式放在path里时，键值的名字是jsessionids,详细的代码例如以下：
另一点就是sessionId默认指定的长度是16个字节,这个在SessionIdGenerator当中指定：
这个 SessionIdGenerator应该是tomcat7的。我在6上源代码找不到。
关于tomcat6的源代码里面。有这种方法generateSessionId：
protected synchronized String generateSessionId() {
byte random[] = new byte[16]; String jvmRoute = getJvmRoute(); String result = null; // Render the result as a String of hexadecimal digits StringBuffer buffer = new StringBuffer(); do { int resultLenBytes = 0; if (result != null) { buffer = new StringBuffer(); duplicates++; } while (resultLenBytes < this.sessionIdLength) { getRandomBytes(random); random = getDigest().digest(random); for (int j = 0; j < random.length && resultLenBytes < this.sessionIdLength; j++) { byte b1 = (byte) ((random[j] & 0xf0) >> 4); byte b2 = (byte) (random[j] & 0x0f); if (b1 < 10) buffer.append((char) ('0' + b1)); else buffer.append((char) ('A' + (b1 - 10))); if (b2 < 10) buffer.append((char) ('0' + b2)); else buffer.append((char) ('A' + (b2 - 10))); resultLenBytes++; } } if (jvmRoute != null) { buffer.append('.').append(jvmRoute); } result = buffer.toString(); } while (sessions.containsKey(result)); return (result); }实现原理：一个随机数加时间加上jvm的id值，jvm的id值会依据server的硬件信息计算得来，因此不同jvm的id值都是唯一的
再补充一点：session本身也是基于kv的hashmap实现的，比方：StandardSession 里面
protected Map attributes = new ConcurrentHashMap();
全部的会话信息的存取都是通过这个属性来实现的。另外上面web.xml的配置有效期tomcat是怎么实现的呢？
就是ManagerBase.processExpires。一直查询全部的session对象。每一个检查是否有效，超期就删除。
详细代码參见
当中session在expire会触发相应的listener事件，从而对session信息进行监控，以下是expire方法部分截图。
**********************总结*********************
在实际运用中session所带来的问题
由上面所描写叙述的session实现机制。我们会发现。为了弥补http协议的无状态的特点。服务端会占用一定的内存和cpu用来存储和处理session计算的开销，这也就是tomcat这个的web容器的并发连接那么低（tomcat官方文档里默认的连接数是200）原因之中的一个。因此非常多java语言编写的站点。在生产环境里web容器之前会加一个静态资源server，比如：apacheserver或nginxserver。静态资源server没有解决http无状态问题的功能，因此部署静态资源的server也就不会让出内存或cpu计算资源专门去处理像session这种功能。这些内存和cpu资源能够更有效的处理每一个http请求，因此静态资源server的并发连接数更高，所以我们能够让那些没有状态保持要求的请求直接在静态server里处理。而要进行状态保持的请求则在java的web容器里进行处理。这样能更好的提升站点的效率
解决session相关问题的技术方案
由上所述，session一共同拥有两个问题须要解决：
1) session的存储应该独立于web容器。也要独立于部署web容器的server。
2）怎样进行高效的session同步。
以下是一篇用zookeeper实现的分布式session方案：