今天在公司加班，突然心血来潮想看看公司一款产品的后管平台登录图片验证码是如何实现的，发现用的方案就是session。首先加载页面时去得到验证码，后台将验证码数字存入到session中，然后在登陆时把前端传入的验证码数字同后台取出的码进行比较，比较之前首先把原来的session移除掉。若相同则验证通过，不同则验证不通过然后重新请求。这个流程本来是没有什么问题的，然而自己突然想到这里会不会有点问题呢？session在并发时会不会出现覆盖的情况呢？然后就动手开始测试。

首先，使用谷歌浏览器在登陆页面A复制一个登陆页面B出来，此时就出现问题了，由于B页面的出现原先的session值已经被覆盖掉了，此时A页面输入验证码后就会提示验证码错误。此时就在想能不能通过新的方案来解决这个问题。既然覆盖的原因是因为session的key相同造成的，那我能不能使用不同的key，那不就行了吗？这时很自然的想到了使用cookie，用cookie来保存一个随机数，每次请求验证码时候设置一个随机数存入cookie，同时session的key就是用这个随机数，并给cookie设置了个过期时间。由于cookie可以覆盖，所以不用担心同一时间，大量的请求问题。

代码完成后，便开始测试，然而并不是想的那么顺利，此时出现了一个困扰了我几个小时的问题。每次浏览器请求时都被写入cookie，可为什么在登陆时就不带上cookie呢？查了各种资料，甚至在java后台那里把请求头no-cache注释掉，都没解决。都快要放弃时，然后突然发现，JSSESSIONID的路径为什么和COOKIE的路径不一样呢？然后查了一些路径方面的资料，终于发现是这个原因了。然后再试试问题就解决了，真是坑了我好久。

然后我又突然想到，session是线程安全的吗，会不会存在着覆盖的情况。仔细分析后发现是安全的，我同时打开谷歌、火狐浏览器，然后使用不同的用户登录系统，发现并没有出现session里用户名被覆盖的情况，原因原来是JSSESSION这个东西，JSSESSIONID表示一个会话，这个会话维护着自己的session，所以不会出现覆盖的情况。这同时也解释了为什么我最初时也就是没有改验证码情况之前，通过两个浏览器不会出现验证码被覆盖的情况。如果通过同一个浏览器来登陆不同用户的话，就会出现用户被覆盖的情况，相比原因大家也都知道，那就是JSSESSIONID是一致造成的。

用了将近一天的时间弄明白了这个问题,同时也对session和cookie的原理有了更加深入的了解。学习技术就应该孜孜不倦，任何异常的产生都是有原因的，解决这个异常的过程虽然很艰难，但是随着不断地深入你会学到很多很多。