(编辑:jimmy 日期: 2024/12/25 浏览:2)
学了 ConcurrentHashMap
却不知如何应用?用了Tomcat的Session却不知其是如何实现的,Session是怎么被创建和销毁的?往下看你就知道了。
Session结构
不多废话,直接上图
仔细观察上图,我们可以得出以下结论
HttpSession
是JavaEE标准中操作Session的接口类,因此我们实际上操作的是 StandardSessionFacade
类Session
保存数据所使用的数据结构是 ConcurrentHashMap
, 如你在图上看到的我们往 Session
中保存了一个msg为什么需要使用 ConcurrentHashMap
呢?原因是,在处理Http请求并不是只有一个线程会访问这个Session, 现代Web应用访问一次页面,通常需要同时执行多次请求, 而这些请求可能会在同一时刻内被Web容器中不同线程同时执行,因此如果采用 HashMap
的话,很容易引发线程安全的问题。
让我们先来看看HttpSession的包装类。
StandardSessionFacade
在此类中我们可以学习到外观模式(Facde)的实际应用。其定义如下所示。
public class StandardSessionFacade implements HttpSession
那么此类是如何实现Session的功能呢"htmlcode">
private final HttpSession session; public StandardSessionFacade(HttpSession session) { this.session = session; }
那么我们为什么不直接使用HttpSession的实现类呢?
根据图1,我们可以知道HttpSession的真正实现类是 StandardSession
,假设在该类内定义了一些本应由Tomcat调用而非由程序调用的方法,那么由于Java的类型系统我们将可以直接操作该类,这将会带来一些不可预见的问题,如以下代码所示。
而如果我们将 StandardSession
再包装一层,上图代码执行的时候将会发生错误。如下图所示,将会抛出类型转换的异常,从而阻止此处非法的操作。
再进一步,我们由办法绕外观类直接访问 StandardSession
吗?
事实上是可以的,我们可以通过反射机制来获取 StandardSession
,但你最好清楚自己在干啥。代码如下所示
@GetMapping("/s") public String sessionTest(HttpSession httpSession) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException { StandardSessionFacade session = (StandardSessionFacade) httpSession; Class targetClass = Class.forName(session.getClass().getName()); //修改可见性 Field standardSessionField = targetClass.getDeclaredField("session"); standardSessionField.setAccessible(true); //获取 StandardSession standardSession = (StandardSession) standardSessionField.get(session); return standardSession.getManager().toString(); }
StandardSession
该类的定义如下
public class StandardSession implements HttpSession, Session, Serializable
通过其接口我们可以看出此类除了具有JavaEE标准中 HttpSession
要求实现的功能之外,还有序列化的功能。
在图1中我们已经知道 StandardSession
是用 ConcurrentHashMap
来保存的数据,因此接下来我们主要关注 StandardSession
的序列化以及反序列化的实现,以及监听器的功能。
序列化
还记得上一节我们通过反射机制获取到了 StandardSession
吗?利用以下代码我们可以直接观察到反序列化出来的 StandardSession
是咋样的。
@GetMapping("/s") public void sessionTest(HttpSession httpSession, HttpServletResponse response) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, IOException { StandardSessionFacade session = (StandardSessionFacade) httpSession; Class targetClass = Class.forName(session.getClass().getName()); //修改可见性 Field standardSessionField = targetClass.getDeclaredField("session"); standardSessionField.setAccessible(true); //获取 StandardSession standardSession = (StandardSession) standardSessionField.get(session); //存点数据以便观察 standardSession.setAttribute("msg","hello,world"); standardSession.setAttribute("user","kesan"); standardSession.setAttribute("password", "点赞"); standardSession.setAttribute("tel", 10086L); //将序列化的结果直接写到Http的响应中 ObjectOutputStream objectOutputStream = new ObjectOutputStream(response.getOutputStream()); standardSession.writeObjectData(objectOutputStream); }
如果不出意外,访问此接口浏览器将会执行下载操作,最后得到一个文件
使用 WinHex
打开分析,如图所示为序列化之后得结果,主要是一大堆分隔符,以及类型信息和值,如图中红色方框标准的信息。
不建议大家去死磕序列化文件是如何组织数据的,因为意义不大
如果你真的有兴趣建议你阅读以下代码 org.apache.catalina.session.StandardSession.doWriteObject
监听器
在JavaEE的标准中,我们可以通过配置 HttpSessionAttributeListener
来监听Session的变化,那么在 StandardSession
中是如何实现的呢,如果你了解观察者模式,那么想必你已经知道答案了。 以setAttribute为例,在调用此方法之后会立即在本线程调用监听器的方法进行处理,这意味着我们不应该在监听器中执行阻塞时间过长的操作。
public void setAttribute(String name, Object value, boolean notify) { //省略无关代码 //获取上文中配置的事件监听器 Object listeners[] = context.getApplicationEventListeners(); if (listeners == null) { return; } for (int i = 0; i < listeners.length; i++) { //只有HttpSessionAttributeListener才可以执行 if (!(listeners[i] instanceof HttpSessionAttributeListener)) { continue; } HttpSessionAttributeListener listener = (HttpSessionAttributeListener) listeners[i]; try { //在当前线程调用监听器的处理方法 if (unbound != null) { if (unbound != value || manager.getNotifyAttributeListenerOnUnchangedValue()) { //如果是某个键的值被修改则调用监听器的attributeReplaced方法 context.fireContainerEvent("beforeSessionAttributeReplaced", listener); if (event == null) { event = new HttpSessionBindingEvent(getSession(), name, unbound); } listener.attributeReplaced(event); context.fireContainerEvent("afterSessionAttributeReplaced", listener); } } else { //如果是新添加某个键则执行attributeAdded方法 context.fireContainerEvent("beforeSessionAttributeAdded", listener); if (event == null) { event = new HttpSessionBindingEvent(getSession(), name, value); } listener.attributeAdded(event); context.fireContainerEvent("afterSessionAttributeAdded", listener); } } catch (Throwable t) { //异常处理 } } }
Sesssion生命周期
如何保存Session
在了解完Session的结构之后,我们有必要明确 StandardSession
是在何时被创建的,以及需要注意的点。
首先我们来看看 StandardSession
的构造函数, 其代码如下所示。
public StandardSession(Manager manager) { //调用Object类的构造方法,默认已经调用了 //此处再声明一次,不知其用意,或许之前此类有父类"text-align: center">我们将目光转移到
ManagerBase
中可以发现以下代码。protected Map<String, Session> sessions = new ConcurrentHashMap<>();
Session
是Tomcat自定义的接口,StandardSession
实现了HttpSession
以及Session
接口,此接口功能更加丰富,但并不向程序员提供。查找此属性可以发现,与Session相关的操作都是通过操作
sessions
来实现的,因此我们可以明确保存Session的数据结构是ConcurrentHashMap
。如何创建Session
那么Session到底是如何创建的呢?我找到了以下方法
ManagerBase.creaeSession
, 总结其流程如下。
(1000*60*counter)/(int)(now - oldest)
其中
public Session createSession(String sessionId) { //检查Session是否超过限制,如果是则抛出异常 if ((maxActiveSessions >= 0) && (getActiveSessions() >= maxActiveSessions)) { rejectedSessions++; throw new TooManyActiveSessionsException( sm.getString("managerBase.createSession.ise"), maxActiveSessions); } //该方法会创建StandardSession对象 Session session = createEmptySession(); //初始化Session中必要的属性 session.setNew(true); //session是否可用 session.setValid(true); //创建时间 session.setCreationTime(System.currentTimeMillis()); //设置session最大超时时间 session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60); String id = sessionId; if (id == null) { id = generateSessionId(); } session.setId(id); sessionCounter++; //记录创建session的时间,用于统计数据session的创建速率 //类似的还有ExpireRate即Session的过期速率 //由于可能会有其他线程对sessionCreationTiming操作因此需要加锁 SessionTiming timing = new SessionTiming(session.getCreationTime(), 0); synchronized (sessionCreationTiming) { //sessionCreationTiming是LinkedList //因此poll会移除链表头的数据,也就是最旧的数据 sessionCreationTiming.add(timing); sessionCreationTiming.poll(); } return session; }
Session的销毁
要销毁Session,必然要将Session从 ConcurrentHashMap
中移除,顺藤摸瓜我们可以发现其移除session的代码如下所示。
@Override public void remove(Session session, boolean update) { //检查是否需要将统计过期的session的信息 if (update) { long timeNow = System.currentTimeMillis(); int timeAlive = (int) (timeNow - session.getCreationTimeInternal())/1000; updateSessionMaxAliveTime(timeAlive); expiredSessions.incrementAndGet(); SessionTiming timing = new SessionTiming(timeNow, timeAlive); synchronized (sessionExpirationTiming) { sessionExpirationTiming.add(timing); sessionExpirationTiming.poll(); } } //将session从Map中移除 if (session.getIdInternal() != null) { sessions.remove(session.getIdInternal()); } }
被销毁的时机
主动销毁
我们可以通过调用 HttpSession.invalidate()
方法来执行session销毁操作。此方法最终调用的是 StandardSession.invalidate()
方法,其代码如下,可以看出使 session
销毁的关键方法是 StandardSession.expire()
public void invalidate() { if (!isValidInternal()) throw new IllegalStateException (sm.getString("standardSession.invalidate.ise")); // Cause this session to expire expire(); }
expire
方法的代码如下
@Override public void expire() { expire(true); } public void expire(boolean notify) { //省略代码 //将session从ConcurrentHashMap中移除 manager.remove(this, true); //被省略的代码主要是将session被销毁的消息通知 //到各个监听器上 }
超时销毁
除了主动销毁之外,我们可以为session设置一个过期时间,当时间到达之后session会被后台线程主动销毁。我们可以为session设置一个比较短的过期时间,然后通过 JConsole
来追踪其调用栈,其是哪个对象哪个线程执行了销毁操作。
如下图所示,我们为session设置了一个30秒的超时时间。
然后我们在 ManagerBase.remove
方法上打上断点,等待30秒之后,如下图所示
Tomcat会开启一个后台线程,来定期执行子组件的 backgroundProcess
方法(前提是子组件被Tomcat管理且实现了 Manager
接口)
@Override public void backgroundProcess() { count = (count + 1) % processExpiresFrequency; if (count == 0) processExpires(); } public void processExpires() { long timeNow = System.currentTimeMillis(); Session sessions[] = findSessions(); int expireHere = 0 ; if(log.isDebugEnabled()) log.debug("Start expire sessions " + getName() + " at " + timeNow + " sessioncount " + sessions.length); //从JConsole的图中可以看出isValid可能导致expire方法被调用 for (int i = 0; i < sessions.length; i++) { if (sessions[i]!=null && !sessions[i].isValid()) { expireHere++; } } long timeEnd = System.currentTimeMillis(); if(log.isDebugEnabled()) log.debug("End expire sessions " + getName() + " processingTime " + (timeEnd - timeNow) + " expired sessions: " + expireHere); processingTime += ( timeEnd - timeNow ); }
我们可以来看看接口中 Manager.backgroundProcess
中注释,简略翻译一下就是 backgroundProcess
会被容器定期的执行,可以用来执行session清理任务等。
/** * This method will be invoked by the context/container on a periodic * basis and allows the manager to implement * a method that executes periodic tasks, such as expiring sessions etc. */ public void backgroundProcess();
总结
Session的数据结构如下图所示,简单来说就是用 ConcurrentHashMap
来保存 Session
,而 Session
则用 ConcurrentHashMap
来保存键值对,其结构如下图所示。 .jpg
这意味着,不要拼命的往Session里面添加离散的数据, 把离散的数据封装成一个对象性能会更加好 如下所示
//bad httpSession.setAttribute("user","kesan"); httpSession.setAttribute("nickname","点赞"); httpSession.setAttribute("sex","男"); ....
//good User kesan = userDao.getUser() httpSession.setAttribute("user", kesan);
如果你为Session配置了监听器,那么对Session执行任何变更都将直接在当前线程执行监听器的方法, 因此最好不要在监听器中执行可能会发生阻塞的方法 。
Tomcat会开启一个后台线程来定期执行 ManagerBase.backgroundProcess
方法用来检测过期的Session并将其销毁。
思想迁移
对象生成速率算法此算法设计比较有趣,并且也可以应用到其他项目中,因此做如下总结。
首先生成一个固定大小的链表(比如说100),然后以null元素填充。 当创建新的对象时,将创建时间加入链表末尾中(当然是封装后的对象),然后将链表头节点移除,此时被移除的对象要么是null节点要么是最早加入链表的节点 当要计算对象生成速率时,统计链表中不为null的元素的数量除以当前的时间与最早创建对象的时间的差,便可以得出其速率。(注意时间单位的转换)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。