按代的垃圾收集机制, 主要分为三种： 复制算法，空间被分为等大的两块，从根开始访问每一个关联的活跃对象，将空间 A 的活跃对象全部复制到空间 B，然后一次性回收整个空间 A，优点：只访问活跃对象，将所有活动对象复制走之后就清空整个空间，不用去访问死对象，所以遍历空间的成本较小，缺点：需要巨大的复制成本和较多的内存； 标记清除算法，从根开始访问所有活跃对象，标记为活跃对象。然后再遍历一次整个内存区域，把所有没有标记活跃的对象进行回收处理，优点：不需要额外的空间，缺点：较长的 GC 暂停时间，较大的扫描时间开销，产生较多的空间碎片； 标记清除整理算法，综合上两种算法的优点，先标记活跃对象，然后将其合并成较大的内存块。 代的划分： 年轻代：新创建的对象分配在此，研究表明，大部分程序所产生的对象都在此消亡，几乎所有的收集器为年轻代使用复制算法，年轻代又被划分为 1个伊甸园区(Eden)和 2个存活区(Survivor)用来实施复制算法； 也称Minor Collection，基于大多数对象Die Young的原则 年老代(Tenured)：从年轻代存活下来的对象被复制到年老代，主要实施标记清除或标记清除整理算法；也称Major Collection， Full GC. 该过程会比较慢因为会遍历所有的Live 对象。 持久代(Permanent)：装载的类数据和方法存储于此，无可消亡对象。 基于JVM层的性能调优思路大概是： 对程序进行profiling, 主要考虑方法调用过程，花费的时间等 dump出heap或者实时监控分析 对象大小，引用关系 启动Java程序时打开 -verbose:gc, 分析GC执行情况，执行前后Heap中对象在图上显示有什么pattern（如果有图形显示的工具的话） 根据分析结果检查线程，死锁，内存泄漏的蛛丝马迹。最后可以考虑对JVM启动参数进行调整，这个会改变GC的算法及内存（heap）分配情况 单处理器时基本是基于Generation的Copy算法或者Mark-Sweep-Compact算法；多处理器时考虑并行GC因此可以指定更多的GC策略，一个处理器做GC，另一个继续运行Applicaiton。这样不用象单处理器一样GC时Applicaiton Pause住。
关系数据库 基于严格的关系数据库理论，但面对现有电子商务，SNS网站业务的挑战，Scalability和Performance不能很好地解决 Key-Value数据库 No SQL数据库如google的Big Table. 解决了关系数据库的不足，但基于Key取值，并不能如同SQL一般进行查询。因为数据都是非结构化，离散的。 面向文档的数据库 如：MongoDB，支持查询 图形数据库 据说已有厂家产品支持节点和边的图形数据库
通过下面的调用链 PUMA接口 Portal,portlets PUMA (Portal User Management Architecture) WMM (Websphere Member Manager) 最终WMM.xml中会配置LDAP连接的信息，从而关联portal server和LDAP server
加入WS-Security Policy？ 在Web Service 前加入网关安全过滤？ 在soap header 中加入user id/caller id, org id/name 的信息。当然别人也可以仿造
SOP(Same Orgin Policy)限制 这个主要通过 JSONP(padding)解决，当然server proxy, iframe也是可选的方案 file upload IFrame是一种方案，其他可选的有Applet, Flash 插件方案。 Backward/Forward/收藏夹 不是很清楚解决方案，记得曾看到过有通过同一个页面加锚点的方案，不是很理解。
堆栈参数调整(基于 Sun Hotspot ) -Xss:设置任何线程的本地方法栈大小 -Xms:设置JVM初始堆大小 -Xmx:设置JVM最大堆大小 -XX:PermSize=:设置JVM Perm generation的初始大小 -XX:MaxPermSize=:设置JVM Perm Generation的最大大小 注意：所有以-X开头的JVM参数都不是标准参数（未包含在JVM规范中），即可能不会被所有版本的JVM实现；以-XX开头的JVM参数可能指定了特定的系统平台，且可能在没有通知的情况下更改，因此不推荐使用。 通过jdk5 自带的JConsole查看是否有memory leak 先以下面的方式启动需要调优的目标程序JVM cd C:\Program Files\Java\jdk1.6.0_21\demo\jfc\SwingSet2 java -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=localhost -jar SwingSet2.jar 打开JConsole(JDK5)/JVisualVM(JDK6)以本地进程方式连接目标进程.查看memory, classes, thread,CPU情况。 注意在我Vista机器上 必须加上 -Djava.rmi.server.hostname=localhost 才能连接，否则报“连接失败，是否重试”的错误。 查看heap中的主要对象，用jmap 可以查看histogram 查看对象的reachable jhat
最近在拜读Martin Fowler的Enterprise Integration Pattern，对于基于消息系统的应用集成了解了不少。虽然以前的工作也涉及IBM MQ但体会总是不是很深。在不同应用，分布式环境中的集成中，消息中间件在可靠性方面是优势。 这跟我的第一印象是刚好相反的，以前总以为消息总会如同发出的信件一下，也许会石沉大海吧？哪有同步方式，比如打电话，可靠？仔细一想，其实不然。同步方式在分布式应用中依赖太多，通讯双方同时在线，网络可靠，load安全（不要被太多的Request压死了）等。 这些方面消息中间件却是优势。同时消息中间件解耦了消息生产者和消费者。发送消息和接收消息的系统只要跟消息中间件打交道。 记得以前有个项目中自己实现了个消息系统，J2SE中多个应用之间通过消息通讯。主要是通过RMI和Observer模式实现。回想起来也算是分布式消息系统吧？不同的是发送方和接受方是耦合的。比如发送方（subject）维护了一个接受方的listener list(RMI 回调接口），发送消息时轮询list并RMI回调接口。 再回想起以前被面的时候，一个经理跟我谈到SOA时，不停的challenge我项目中SOA框架有啥好处。他的意思是他现在项目中用JSP，Servlet分层用的很好啊。然后我就从loosely coupling, reuse等角度来讲这个问题。SOA框架给我们解耦了Service的集成（通过ESB )。如同Spring封装了对象的创建和维护消除我们在自己程序中通过Factory，Singleton来创建对象，框架帮我们做了这部分工作。
为了安全起见，所有的写操作都要计入Audit表中 考虑效率（reconciliation&settlement)，引入影子表（这是一个实表，非虚表）. 影子表是对多个业务相关表的数据冗余。 数据库表设计时留了一些字段,并不表示任何业务意义，仅仅是为了以后扩充。虽丑陋但实用，能解决部分问题。 表结构设计时不设主键外键，提高性能？ Portal支持SSL 逻辑删除表记录，如结算，对账中用到的帐号信息。 7. 虽然是BS结构的网站，从网络层面配置可访问的IP地址--白名单。 8. 系统自己定义一些业务规则并在payment流程中验证这些规则。 现在很多网上支付系统加入了短信验证码的机制