Tomcat

故障现象： 1：活动前端Nginx服务器TCP连接数到1万多 2：活动后端Tomcat其中1台TCP连接数达4千，并且CPU瞬间到780%（配置8核16G），内存正常 3：重启后端Tomcat后，TCP连接数正常，但是持续1~2天，TCP连接数暴增，仍需再次重启 故障分析： Tomcat服务器TCP连接数上升，并发现象 1：Tomcat服务器内存异常，每次重启后一段时间内存使用到一定阶段后出现问题 2：Tomcat服务器top命令，服务进程异常，占用内存到4.4G后，出现CPU使用异常飙升 故障分析结论 1：Tomcat堆内存使用出现问题，GC资源回收次数增长和回收时长增加，最终导致CPU资源异常和TCP连接数飙升 故障分析结论验证 验证方法： 监控Tomcat服务JVM堆内存使用情况 Tomcat启动脚本添加 JAVA_OPTS="-Dfile.encoding=utf-8 -javaagent:/home/tomcat_games/lib/jmxtrans-agent-1.2.6.jar=/home/tomcat_games/conf/jmxtrans-agent.xml " 并将数据收集到elasticsearch HEAP内存使用数据绘图如下： 堆内存使用超过最大允许值，直线下降部分是服务重启 故障定位： 查找具体什么原因导致堆内存无法释放 故障定位方法一： jmap

Docker的镜像服务器 1. https://hub.docker.com搜索registry 2. docker pull registry 3. 创建目录并编辑配置文件，如下图： 4. 配置内容如下： version:'3.1' services: registry: image:registry restart:always container_name:registry ports: - 5000:5000 volumes: - /usr/local/docker/registry/data:/var/lib/registry 5. 如图所示： 6.启动：docker-compose up -d 7. 访问：ip:5000/v2/ 8. 加速器的文件 /etc/docker/daemon.json中配置添加如下内容 "insecure-registries":["ip:5000"] 9. 如下图所示： 10. 保存退出编辑器 11. 重启服务 systemctl daemon- reload systemctl restart docker 12. 查看是否配置成功 docker info 13. 测试上传功能，先从中央仓库拉取一个tomcat镜像 docker pull tomcat 14. 查看全部镜像 docker images 15. 标记本地镜像并指向目标仓库

点击上方 " 程序员小乐 "关注, 星标或置顶一起成长 每天凌晨00点00分, 第一时间与你相约 每日英文 It is our choices... that show what we truly are, far more than our abilities.J. K. Rowling . 决定我们一生的，不是我们的能力，而是我们的选择。 每日掏心 话 没有不能改变的事，因为自己改变了，状况也就跟着转变。 来自 ： ava未来的大佬 | 责编：乐乐 链接：cnblogs.com/heqiyoujing/p/10917102.html 程序员小乐(ID:study_tech) 第 959 次推文 图源：百度 往日回顾： 程序员吐槽：入职两周，怀疑自己进了假百度！跟传说中完全不一样 正文 一、分布式session 　　session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存在，然后每次发请求过来都带上一个特殊的 jsessionid cookie ，就根据这个东西，在服务端可以维护一个对应的 session 域，里面可以放点数据。 　　一般的话只要你没关掉浏览器，cookie 还在，那么对应的那个 session 就在，但是如果 cookie 没了，session 也就没了。常见于什么购物车之类的东西，还有登录状态保存之类的。 　　这个不多说了，懂

一、分布式session 　　session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存在，然后每次发请求过来都带上一个特殊的 jsessionid cookie ，就根据这个东西，在服务端可以维护一个对应的 session 域，里面可以放点数据。 　　一般的话只要你没关掉浏览器，cookie 还在，那么对应的那个 session 就在，但是如果 cookie 没了，session 也就没了。常见于什么购物车之类的东西，还有登录状态保存之类的。 　　这个不多说了，懂 Java 的都该知道这个。 　　单块系统的时候这么玩儿 session 没问题，但是你要是分布式系统呢，那么多的服务，session 状态在哪儿维护啊？ 　　（1）完全不用 session 　　使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓 　　（2）tomcat + redis 　　这个其实还挺方便的，就是使用 session 的代码，跟以前一样，还是基于 tomcat 原生的 session 支持即可，然后就是用一个叫做 Tomcat RedisSessionManager 的东西，让所有我们部署的 tomcat 都将 session 数据存储到 redis 即可。 　　在 tomcat 的配置文件中配置：

[size=large] 通过URL传中文参数时，在服务端后台获取到的值往往会出现乱码。解决方案有很多种。本文介绍如何通过encodeURI来解决中文乱码问题。 首先，在前端页面准备参数的时候，需要对中文参数进行encode处理： var url = 'HelloWorldServlet?star_name=' + encodeURI(encodeURI( "刘德华" )); window.open(url); 其次，在服务端后台程序代码中用java.net.Decoder进行解码，从而得到中文参数的真实值： String starName = java.net.URLDecoder.decode(request.getParameter("star_name"),"UTF-8"); 目的达到了。哈哈，很简单吧。不过此时你可能有个疑问，前端在进行encode编码是，为什么用了两次encodeURI，而服务器后端在解码时只解了一次？ 原因是：容器会默认帮你解一次码。 此时，你可能又要问了，既然容器会默认解一次码，那么为什么不直接在前端只进行一次encode，服务端程序直接request.getParameter(“star_name”) ？画蛇添足了吧？ 原因是：容器默认解码时采用的编码是容器的默认编码，可能是UTF-8，GBK，也可能是其他编码方式。这与你的应用的编码方式未必会一致

目录 面试问道这个我居然不知道怎么回答，当然也是因为我确实没有研究过。下面就是百度了一篇文章后简单回答这个问题。 参考： http://www.cnblogs.com/sharpxiajun/p/3395607.html http://lavasoft.blog.51cto.com/62575/275589/ sessionid是一个会话的key， 浏览器第一次访问服务器会在服务器端生成一个session ，有一个sessionid和它对应。 tomcat生成的sessionid叫做jsessionid 。 session在访问tomcat服务器HttpServletRequest的getSession(true)的时候创建 ，tomcat的ManagerBase类提供创建sessionid的方法： 随机数+时间+jvmid； 存储在服务器的内存中，tomcat的StandardManager类将session存储在内存中，也可以持久化到file，数据库，memcache，redis等。客户端只保存sessionid到cookie中，而不会保存session，session销毁只能通过invalidate或超时，关掉浏览器并不会关闭session。 那么Session在何时创建呢？当然还是在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同创建Session的方法