关于项目里面经常用到的技术之一，cookie和session机制。或许很多人对于这个机制的了解只是比较粗浅，所以这一次就来深入剖析一下cookie和session的内容吧。
关于javaee里面的cookie而言，可以理解为，每一次客户端请求一次服务端之后，服务器返回给客户端的一个标识。这种标识类似于k，v的模式存在，每个浏览器再次请求服务器的时候就需要携带这个标识，从而让服务端来认证。
但是对于cookie的认识光有这些还不够，接下来我们从几个常用的场景来进行分析：
1. cookie大小设置
假若面临一个业务场景，如果一个网站的pv数据量为1亿，那么cookie的大小设置在200字节左右，得占用多么大的带宽啊！
对于普通中小型企业的项目，性能优化方面，我们可以从cookie的大小方面来进行设置。
2. cookie的版本
关于cookie的历史版本而言，他有两种版本，分别是version0和version1
版本0 : 由Netscape公司制定的，也被几乎所有的浏览器支持。Java中为了保持兼容性, 目前只支持到版本0, Cookie的内容中不能空格，方括号，圆括号，等于号（=），逗号，双引号，斜杠，问号，@符号，冒号，分号。
版本1 : 根据RFC2109文档制定的。放宽了很多限制。版本0中所限制的字符都可以使用。但为了保持兼容性，程序开发者都会尽量避免使用这些特殊字符
3. cookie的作用域
不同的cookie分别都会有自己的作用域，例如说谷歌网站的cookie就只有访问google的时候会携带，facebook的cookie也只有访问facebook的时候会携带，不会出现访问facebook网站的时候携带上google的cookie
4. cookie的生命周期
每个cookie都会有自己的生命周期，一旦过了生命周期时间范围，cookie就会过期。
例如一下代码：
Cookie c = new Cookie(“username”,”john”);
c.setMaxAge(60);//60秒的意思
c.setMaxAge(60*60);//一小时
c.setMaxAge(365*24*60*60);//一年
如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。
这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
Session
对于session而言，它相较于cookie会安全许多。Session一般译为会话，是解决Http协议的无状态问题的方案，可以将一次会话中的数据存储在服务器端的内存中，保证在下一次的会话中可以使用。
在客户端浏览器第一次向服务器端发送请求时，服务器端会为这个客户端创建独有的Session，并具有唯一的Session ID，存储在服务器端的内存中。在客户端第二次访问服务器端时，会携带Session ID在请求中，服务器端会根据Session ID查找对应的Session信息，进行进一步地操作。
在JavaEE中提供了javax.servlet.http.HttpSession接口，通过该接口可以将共享的数据内容存储在HttpSession对象中，从而解决Http协议的无状态问题。
那么光是了解session的这些还不够，接下来让我们深入session的内部进行研究。
关于session的内部研究，可以如下进入：
自己编写一个简单的servlet，然后开启tomcat，设置成debug模式，打一个断点，当请求该servlet的时候，程序会在断点处停止。
这个时候，查看调试窗口里面的内容，会发现一下内容：
咦，这个standardsession是个什么鬼东西，推测这个standardsession是httpsession接口的实现类来的。后来经过谷歌查询，发现standardsession的存放位置在org.apache.session.StandardSession，看到这个包名，我猜测是tomcat目录里面lib文件夹里面的jar包之一。后来经过一定的查找，发现这个类是存放在一个叫做catalina的jar里面。果然一打开jar，全部都是新世界。
果然找到了StandardSession这个类。
看到一个ConcurrentMap集合之后，就大概明白session.setAttribute的真正原理了，ConcurrentMap是一个采用了分段锁来解决线程安全的一种map类型，它的出现解决了了HashTable里面使用synchronized加锁效率低的不足之处，关于什么是分段锁，以后有时间我再写一篇文章来总结一下。
再往深处看，我们可以看到session.setattribute里面的内容：
嗯嗯，注入一个属性的源码实现就是这样的，那么这个方法又是怎么调用的呢？
其实这里面有涉及到一中设计模式的思想，叫做门面模式。
首先来看session的时序图：
我的理解是，首先请求到request.getsession,然后创建一个新的session对象，并且将相应的session对象存放到session容器当中。由manager来对这个容器进行保存。manager类将进行对于session的生命周期管理。
关于findsession函数，主要由ManagerBase（有些书上边说是StandardManager
，其实StandardManager是ManagerBase的子类）负责实现，里面的代码如下所示：
而这里面代码出现的sessions其实是这么个东西：
protected Map<String, Session> sessions = new ConcurrentHashMap();
通过findsession函数可以返回一个org.apache.catalina.Session的接口，Session这个接口里面包含了许多的属性，其中包含有HttpSession这个属性。
在HttpSession接口里面，包含有相应的内容，看到源码这里的时候，大概就有点熟悉的味道了。
