| Tomcat源码分析 （十） | 您所在的位置：网站首页 › tomcat设置session失效时间 › Tomcat源码分析 （十） |
Tomcat源码分析 （十）
|
Tomcat Session 概述
首先 HTTP 是一个无状态的协议, 这意味着每次发起的HTTP请求, 都是一个全新的请求(与上个请求没有任何联系, 服务端不会保留上个请求的任何信息), 而 Session 的出现就是为了解决这个问题, 将 Client 端的每次请求都关联起来, 要实现 Session 机制 通常通过 Cookie(cookie 里面保存统一标识符号), URI 附加参数, 或者就是SSL (就是SSL 中的各种属性作为一个Client请求的唯一标识), 而在初始化 ApplicationContext 指定默认的Session追踪机制(URL + COOKIE), 若 Connector 配置了 SSLEnabled, 则将通过 SSL 追踪Session的模式也加入追踪机制里面 (将 ApplicationContext.populateSessionTrackingModes()方法) Cookie 概述Cookie 是在Http传输中存在于Header中的一小撮文本信息(KV), 每次浏览器都会将服务端发送给自己的Cookie信息返回发送给服务端(PS: Cookie的内容存储在浏览器端); 有了这种技术服务端就知道这次请求是谁发送过来的(比如我们这里的Session, 就是基于在Http传输中, 在Cookie里面加入一个全局唯一的标识符号JsessionId来区分是哪个用户的请求) Tomcat 中 Cookie 的解析在 Tomcat 8.0.5 中 Cookie 的解析是通过内部的函数 processCookies() 来进行操作的(其实就是将Http header 的内容直接赋值给 Cookie 对象, Cookie在Header中找name是"Cookie"的数据, 拿出来进行解析), 我们这里主要从 jsessionid 的角度来看一下整个过程是如何触发的, 我们直接看函数 CoyoteAdapter.postParseRequest() 中解析 jsessionId 那部分 // 尝试从 URL, Cookie, SSL 回话中获取请求的 ID, 并将 mapRequired 设置为 false String sessionID = null; // 1. 是否支持通过 URI 尾缀 JSessionId 的方式来追踪 Session 的变化 (默认是支持的) if (request.getServletContext().getEffectiveSessionTrackingModes().contains(SessionTrackingMode.URL)) { // 2. 从 URI 尾缀的参数中拿取 jsessionId 的数据 (SessionConfig.getSessionUriParamName 是获取对应cookie的名字, 默认 jsessionId, 可以在 web.xml 里面进行定义) sessionID = request.getPathParameter( SessionConfig.getSessionUriParamName(request.getContext())); if (sessionID != null) { // 3. 若从 URI 里面拿取了 jsessionId, 则直接进行赋值给 request request.setRequestedSessionId(sessionID); request.setRequestedSessionURL(true); } } // Look for session ID in cookies and SSL session // 4. 通过 cookie 里面获取 JSessionId 的值 parseSessionCookiesId(req, request); // 5. 在 SSL 模式下获取 JSessionId 的值 parseSessionSslId(request); /** * Parse session id in URL. */ protected void parseSessionCookiesId(org.apache.coyote.Request req, Request request) { // If session tracking via cookies has been disabled for the current // context, don't go looking for a session ID in a cookie as a cookie // from a parent context with a session ID may be present which would // overwrite the valid session ID encoded in the URL Context context = request.getMappingData().context; // 1. Tomcat 是否支持 通过 cookie 机制 跟踪 session if (context != null && !context.getServletContext() .getEffectiveSessionTrackingModes().contains( SessionTrackingMode.COOKIE)) { return; } // Parse session id from cookies // 2. 获取 Cookie的实际引用对象 (PS: 这里还没有触发 Cookie 解析, 也就是 serverCookies 里面是空数据, 数据还只是存储在 http header 里面) Cookies serverCookies = req.getCookies(); // 3. 就在这里出发了 Cookie 解析Header里面的数据 (PS: 其实就是 轮训查找 Header 里面那个 name 是 Cookie 的数据, 拿出来进行解析) int count = serverCookies.getCookieCount(); if (count = 0) && (getActiveSessions() >= maxActiveSessions)) { rejectedSessions++; throw new TooManyActiveSessionsException( sm.getString("managerBase.createSession.ise"), maxActiveSessions); } // Recycle or create a Session instance // 创建一个 空的 session // 2. 创建 Session Session session = createEmptySession(); // Initialize the properties of the new session and return it // 初始化空 session 的属性 session.setNew(true); session.setValid(true); session.setCreationTime(System.currentTimeMillis()); // 3. StandardSession 最大的默认 Session 激活时间 session.setMaxInactiveInterval(this.maxInactiveInterval); String id = sessionId; // 若没有从 client 端读取到 jsessionId if (id == null) { // 4. 生成 sessionId (这里通过随机数来生成) id = generateSessionId(); } //这里会将session存入Map sessions = new ConcurrentHashMap(); session.setId(id); sessionCounter++; SessionTiming timing = new SessionTiming(session.getCreationTime(), 0); synchronized (sessionCreationTiming) { // 5. 每次创建 Session 都会创建一个 SessionTiming, 并且 push 到 链表 sessionCreationTiming 的最后 sessionCreationTiming.add(timing); // 6. 并且将 链表 最前面的节点删除 sessionCreationTiming.poll(); } // 那这个 sessionCreationTiming 是什么作用呢, 其实 sessionCreationTiming 是用来统计 Session的新建及失效的频率 (好像Zookeeper 里面也有这个的统计方式) return (session); } @Override public void add(Session session) { //将创建的Seesion存入Map sessions = new ConcurrentHashMap(); sessions.put(session.getIdInternal(), session); int size = getActiveSessions(); if( size > maxActive ) { synchronized(maxActiveUpdateLock) { if( size > maxActive ) { maxActive = size; } } } } } @Override public void setId(String id) { setId(id, true); } @Override public void setId(String id, boolean notify) { if ((this.id != null) && (manager != null)) manager.remove(this); this.id = id; if (manager != null) manager.add(this); if (notify) { tellNew(); } }其主要的步骤就是: 1. 若 request.Session != null, 则直接返回 (说明同一时刻之前有其他线程创建了Session, 并且赋值给了 request) 2. 若 requestedSessionId != null, 则直接通过 manager 来进行查找一下, 并且判断是否有效 3. 调用 manager.createSession 来创建对应的Session，并将Session存入Manager的Map中 4. 根据 SessionId 来创建 Cookie, 并且将 Cookie 放到 Response 里面 5. 直接返回 Session Session清理 Background 线程前面我们分析了 Session 的创建过程，而 Session 会话是有时效性的，下面我们来看下 tomcat 是如何进行失效检查的。在分析之前，我们先回顾下 Container 容器的 Background 线程。 tomcat 所有容器组件，都是继承至 ContainerBase 的，包括 StandardEngine、StandardHost、StandardContext、StandardWrapper，而 ContainerBase 在启动的时候，如果 backgroundProcessorDelay 参数大于 0 则会开启 ContainerBackgroundProcessor 后台线程，调用自己以及子容器的 backgroundProcess 进行一些后台逻辑的处理，和 Lifecycle 一样，这个动作是具有传递性的，也就
关键代码如下所示： ContainerBase.java protected synchronized void startInternal() throws LifecycleException { // other code...... // 开启ContainerBackgroundProcessor线程用于处理子容器，默认情况下backgroundProcessorDelay=-1，不会启用该线程 threadStart(); } protected class ContainerBackgroundProcessor implements Runnable { public void run() { // threadDone 是 volatile 变量，由外面的容器控制 while (!threadDone) { try { Thread.sleep(backgroundProcessorDelay * 1000L); } catch (InterruptedException e) { // Ignore } if (!threadDone) { processChildren(ContainerBase.this); } } } protected void processChildren(Container container) { container.backgroundProcess(); Container[] children = container.findChildren(); for (int i = 0; i < children.length; i++) { // 如果子容器的 backgroundProcessorDelay 参数小于0，则递归处理子容器 // 因为如果该值大于0，说明子容器自己开启了线程处理，因此父容器不需要再做处理 if (children[i].getBackgroundProcessorDelay() = maxInactiveInterval则判定当前 Session 过期了，而这个 thisAccessedTime 参数在每次访问都会进行更新 public boolean isValid() { // other code...... // 如果指定了最大不活跃时间，才会进行清理，这个时间是 Context.getSessionTimeout()，默认是30分钟 if (maxInactiveInterval > 0) { int timeIdle = (int) (getIdleTimeInternal() / 1000L); if (timeIdle >= maxInactiveInterval) { expire(true); } } return this.isValid; }而 expire 方法处理的逻辑较繁锁，下面我用伪代码简单地描述下核心的逻辑，由于这个步骤可能会有多线程进行操作，因此使用 synchronized 对当前 Session 对象加锁，还做了双重校验，避免重复处理过期 Session。它还会向 Container 容器发出事件通知，还会调用 HttpSessionListener 进行事件通知，这个也就是我们 web 应用开发的 HttpSessionListener 了。由于 Manager 中维护了 Session 对象，因此还要将其从 Manager 移除。Session 最重要的功能就是存储数据了，可能存在强引用，而导致 Session 无法被 gc 回收，因此还要移除内部的 key/value 数据。由此可见，tomcat 编码的严谨性了，稍有不慎将可能出现并发问题，以及出现内存泄露 public void expire(boolean notify) { //1、校验 isValid 值，如果为 false 直接返回，说明已经被销毁了 synchronized (this) { // 加锁 //2、双重校验 isValid 值，避免并发问题 Context context = manager.getContext(); if (notify) { Object listeners[] = context.getApplicationLifecycleListeners(); HttpSessionEvent event = new HttpSessionEvent(getSession()); for (int i = 0; i < listeners.length; i++) { //3、判断是否为 HttpSessionListener，不是则继续循环 //4、向容器发出Destory事件，并调用 HttpSessionListener.sessionDestroyed() 进行通知 context.fireContainerEvent("beforeSessionDestroyed", listener); listener.sessionDestroyed(event); context.fireContainerEvent("afterSessionDestroyed", listener); } //5、从 manager 中移除该 session //6、向 tomcat 的 SessionListener 发出事件通知，非 HttpSessionListener //7、清除内部的 key/value，避免因为强引用而导致无法回收 Session 对象 } }由前面的分析可知，tomcat 会根据时间戳清理过期 Session，那么 tomcat 又是如何更新这个时间戳呢？ tomcat 在处理完请求之后，会对 Request 对象进行回收，并且会对 Session 信息进行清理，而这个时候会更新 thisAccessedTime、lastAccessedTime 时间戳。此外，我们通过调用 request.getSession() 这个 API 时，在返回 Session 时会调用 Session#access() 方法，也会更新 thisAccessedTime 时间戳。这样一来，每次请求都会更新时间戳，可以保证 Session 的鲜活时间。 org.apache.catalina.connector.Request.java protected void recycleSessionInfo() { if (session != null) { session.endAccess(); // 更新时间戳 } // 回收 Request 对象的内部信息 session = null; requestedSessionCookie = false; requestedSessionId = null; requestedSessionURL = false; requestedSessionSSL = false; }org.apache.catalina.session.StandardSession.java public void endAccess() { isNew = false; if (LAST_ACCESS_AT_START) { // 可以通过系统参数改变该值，默认为false this.lastAccessedTime = this.thisAccessedTime; this.thisAccessedTime = System.currentTimeMillis(); } else { this.thisAccessedTime = System.currentTimeMillis(); this.lastAccessedTime = this.thisAccessedTime; } } public void access() { this.thisAccessedTime = System.currentTimeMillis(); }
|
【本文地址】