阶段性总结
java方面的：
1、java编译和类加载机制
2、jvm的内存体系结构图和垃圾收集器
3、并发包的实现
4、线程的同步，synchronized，volidate的实现应用,notify和wait的内部原理，每个对象都有阻塞和就绪的线程队列。
5、接口和抽象、反射在框架中的应用
6、设计模式 代理模式，观察者模式，单例模式
7、jvm调优的案例
1、遇到promotion faile（晋升失败的案例），一般有两种原因，1、救助空间不够，但救助空间还不应该被移动到年老空间，看年轻代又又很多对象要放入救助空间。 2、年老空间没有足够的空间来容纳年轻移来的对象。这两种情况都会转向Full GC，网站停顿时间较长。第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。
2、采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿，
3、时不时down的原因查找，先用jmap查看堆内的基本信息，再用top查看系统负载，再用jstat -gcutil 查看垃圾回收的信息，然后猜测可能的原因，然后在用kill -3 查看线程系信息，发现哟死锁的情况。
项目经验方面： 1、表现层方面的演变，数据传递的方式。
2、数据库分库，如何实现数据的传递，websevices和中间表的方式，分析
两种方式的优劣。
用webservice出现的问题：
a. 数据不可靠.(理赔系统和承保系统在传送数据的时候出现网络问题,导致数据没有传递过去.而在这种情况下,根据业务环境的需要,还不能做回滚操作.)
b. 事务无法保障.(这个是webservice处理的典型问题,我也没有好的解决方案).
c. 并发问题.(如:中心系统在进行订单修改提交的时候,门店送出订单).
针对以上三点的解决方案：
1. 如果你的网络环境极其不稳定，可以考虑使用异步流程，比如引入消息服务器(MQ）或者ESB。这样可以确保数据会发送。另外，即使网络环境稳定，也要控制订单数据的大小，最好限制在50K一下，这样，数据因为网络问题产生的影响会降低；第三，在你的服务端，应该启用异步处理流程，将接受订单和处理订单（包括存储数据库等操作）逻辑异步分开，避免业务逻辑事务过长导致webservice响应时间长而引起的问题（也能降低并发访问时的性能问题）。
2. 其实Webservice有事务协议，也就是WS-Transaction，只是目前比较少人用而已。你首先看看你的门店系统和中心系统的 webservice服务器是否支持该协议。另外，如你第一个问题所说，出现问题还不能回滚，说明其实两者并非相同事务，只是需要进行一些补偿事务而已。如果是这样，其实是两个系统不需要担心事务问题，只是需要增加一个机制来确保数据传递的可靠性（而这个又是MQ应用场景的擅长之处了），所以建议你考虑引入MQ。
3. 同一个数据在不同的界面或者用户同时操作带来的数据保证问题，可以使用乐观锁或者悲观锁来解决了，根据你的需要决定。比如如果使用乐观锁，那么有两个字段来描述版本戳（一个描述原先的，一个描述新产生的，比如+1），门店送出订单后，版本戳已经改变，这个时候，中心修改订单想提交就会提示版本冲突，至于是选择放弃策略还是覆盖，或者同步显示在界面让用户修改完全在于你们的设计方案了。这个问题另外有个潜在的约束，在门店提交订单后不能修改（或者与门店修改相同的字段或者中心不能将修改内容发回门店），因为你的数据会存在两个数据库（中心和门店），那样不能完全依靠数据库的锁机制，需要自己做一些补充。
3、前端的负载均衡
4、session的黏贴复制。
5、报表的缓存处理。
6、综合查询的读写分离。
7、sql的调优步骤。
数据库方面的：
3、数据库调优方面
1、垂直分离，按产品的功能分库
2、水平分离，进行表分区
3、读写分离，主从复制
4、大表的索引建立
5、sql调优，执行统计分析
6、事务级别：1、读未提交 2、读提交 3、串行
7、悲观锁和乐观锁的应用。
8、索引的数据机构。用B树实现的，索引列不能为空，空的字段是不能在B树上的，二茶树，数据量多的时候会退化成线性查找，B树查找最多只进行3次IO操作，索引节点是有顺序的。
9、数据库调优的案例
a、通过设置而sql_trace跟踪文件，发现有隐形转换，导致无法用索引。如何看懂统计信息。
b、调优like 'aa%'的例子，做函数索引。
c、定期top 100条sql进行优化，出现加索引和补充聚合索引，增加前导索引，和改变可以为的空条件限制。
d、大表增加索引的出来方法，前期规划非常重要。
e、index_desc报表查询的优化。
f、递归查询的优化。
h、对表执行统计信息，对数据量经常导入导出的做统计信息。
web框架方面
根据自己企业系统量身定制的，每个产品的需求、框架都不一样的。
现在有些项目采用struts2，jsf之类的，所以页面上的值自动绑定到action了，也不用像以前再从request里面取了，很多action的作用就是把自动绑定的值传给service层（顶多是做个类型转换），然后通过service返回的参数进行跳转。
Action的作用是很小，但是不能和Service/Action合并在一起，因为Action属于表现层 而Service属于业务层，多层架构不能破坏，在actio层可以做些数据页面的初始化和更新，做些方法的调用，使表现层能直接调用到匹配的方法。Action本来就是一个前后台调度的调度者，将前台用户输入传递到后台业务处理，将业务处理结果再传递到前台界面，Action就是一个二传手。
struct2在控制层方面进行跨度比较大的创新，传统的值传递方式。。。。，它不是通过方法参数传递的，而是通过threadlocal来传递的，这样的好处是实现了解耦，方便测试。
对于表现层框架：MVC是基本，事件驱动是方向。
我觉得发展方向应该是UI逻辑和数据分离，browser端使用RIA实现UI，而Server端只提供数据和业务逻辑。
事件驱动是一个方向，至于是象JSF那样包装起来，还是使用AJAX都值得试验，可能后者更适合一些，这些都是次要的，关键是：如果我们的界面不实现事件驱动，我们的Browser就不可能完全替代专有语言开发的胖客户端，你看看J2ME+Polish的客户端开发起来多么方便，一个Form继承以后，只要实现事件激发的commandAction，各种命令只要放入这个UI container就可以,其余界面展现只要用CSS实现就可以，这才是高效率的表现层技术啊. 我相信将来在B/S结构中会出现这样好的事件驱动框架.
Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题 。
集群方面
高性能方面
开源框架方面
1、spring IOC，事务处理原理
2、ehcache
缓存的清楚算法LRU，LFU，加入缓存的时候才清楚的，并不是全局扫描的，集群的实现原理，用socket心跳检查存活的节点，用RMI实现复制功能。
新技术方面：
1、node.js
2、nosql方面的memlink
所有的数据都保存在内存中、使用块状压缩内存，持久性方案采用redo方案，保证持久性，分布式方面采用主从复制的，线程方面采用异步的IO模型，来管理并发线程，才用读写线程分离，在高并发的情况下保证写线程也能优先完成，数据结构采用hashtable，不使用锁机制保证高并发性。
3、tiwwer的消息中间件的实现和美团网的简易实现方案
4、mina
企业架构和社交媒体web.20架构是不一样的。
企业架构性能不是至上，精确不出错是至上；而社交媒体架构是可伸缩性性能至上，因为社区系统用户是不断增加的。
JavaEE架构是企业软件架构，包括关系数据库，都不是非常适合社交媒体架构，你提及的几个技术是企业软件架构。
ORM个人比较喜欢ibatis，
半自动ORM，感觉可以（很容易的）掌控开发细节。
包括sql等等
复杂系统的调优：
系统拆分：解决系统复杂性的唯一方法是分解。同时拆分后系统也使各自进行新的技术
改造变得相对平滑。我们从终端渠道、业务逻辑、使用部门等多个维度进行了系统拆分。
适当放弃一致性：在一些实时性要求不高的场合，我们适当放弃一致性要求。这样就可
以充分利用多种手段来提高系统吞吐量，例如页面缓存、分布式数据缓存、数据库读写
分离、查询数据搜索索引化。
