1.先看现成的，可以直接用的
*如果是代码，直接先跑demo，然后再研究
*如果有现成的或者之前已经写好的功能，先去看他们如何实现的，再添加
++++++++++++++待整理+++++++++++++++++++++
1.webxml的配置文件详解
2.DES是什么，如何加密
3.token是什么，如何使用
4.数据从前台输入到后台db然后再反向的传递过程
5.三个web服务器的端口/路径/log配置
6.session和cookie如何储存和生命周期
7.JVM调优
8.HTTP协议
9.TCP/IP协议
10.序列化
11.枚举
12.web服务器配置
13.servlet接口
14.tomcat加载过程
15.类加载器
16.双亲委派模型
17.gc
18.sti
19.jvm
20.rmi
21.token过期异常
22.redis和memcache在db更改的时候同步更改
23.在jmeter测试mysql的时候，线程消耗在什么地方
jsp controller获取数据的时间
servlet获取数据的时间
从mysql中查询到数据的时间
+++++++++++++++++++++++++++++++++++++++++
* 1.项目中遇到一个自己不会的知识点,先去其他项目找类似的解决方法,先粘贴复制过来,看是否能够跑通,如果能够跑通就继续进行.
*
2.如果因为项目的具体要求,需要做一定的变动,那就看自己时候对概念理解透彻了,能否针对项目做具体的修改.如果不能,就需要看源码,看他们怎么操作实现的,如果源码看不明白,针对看不明白的部分进行搜索,理解,比如cookie(键值对),浏览器的存储机制的概念,token的概念区别.
*
3.对于遇到的知识点,问题进行记录,总结,然后在项目间歇期或者自由时间自己进行升级,将知识系统化.
++++++++++++++++++++++++++++++++++++++++
代码不超过50行，低耦合，高内聚，复用性，压缩性
严于律己宽以待人
高内聚：模块功能专一性高，独立性强
低耦合：模块之间联系尽量少
联系紧密
在模块划分时，要遵循“一个模块，一个功能”的原则，尽可能使模块达到功能内聚
高内聚，低耦合的系统有什么好处呢？事实上，短期来看，并没有很明显的好处，甚至短期内会影响系统的开发进度，因为高内聚，低耦合的系统对开发设计人员提出了更高的要求。高内聚，低耦合的好处体现在系统持续发展的过程中，高内聚，低耦合的系统具有更好的重用性，维护性，扩展性，可以更高效的完成系统的维护开发，持续的支持业务的发展，而不会成为业务发展的障碍。
第一 查找知识的能力
第二 描述问题的能力
第三 总结收获的能力
第四 解决问题的能力
第五 构建技能的能力
第五 遵守规范的能力
“对缓存来说，最关键的设计就在于失效策略是什么。”大神镇定的看着我。
不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。
对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。
根据不同的应用需要，去设计不同的策略，同时把这些场景规范化，成为一整个团队都要去遵循的标准？
每一个技术框架的选择，都经过讨论，验证，测试，最终在全团队里推行。
这是否也是架构师的职责？这个架构师太厉害了，他需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。
他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。
完整的看过TCP/IP协议详解