刚有人问面试题咋答，一时兴起回了下，关于对 Struts2, Spring 和 Hibernate 的理解

我都好久没写过简历了。最近新做了一个公式解析的开源小项目，还不到 1 万行程序。不过准备改改简历。
我就准备写“算法精通”，然后 Java 编程也想写一个“专精”。嘿嘿。

不过感觉如果英语水平像我这样不过关，算法岗位就是完全没有啊……

拍拍胸脯，其实我是做算法出身的，
……
不过……大学学的是化学，写的是哲学的毕业论文……

小时候一直在做纯程序层的算法，给爸爸联系来的各种项目帮忙。以至于我高中毕业的时候，基于我算法的产品（一款数码相册产品1999年）都开始卖了，我还连数据库是什么都不知道……

我刚参加工作的时候确实有孤高的问题。总觉得自己掌握了工程学的要义，别人做的这个那个都不合理——关键是当时和别人交流的意识也极差，所以工作很不顺利。除了给新华社做了个与中央国债同步数据的项目，因为是我自己一个人不存在沟通问题所以还做得不错以外，别的都很失败。这几年在上市公司负责服务器，管各种人，我就变得学会主动和别人交流；希望他们不再出现我以前的那些问题。
　　我早就不是毕业生了，不过看到您的帖子，还是让我看到了您对一个毕业生关注和帮助。非常感谢您。  :-)

真不夸大，请参看第四页回帖我给出的数据……
那个内存十倍以上，也是实用的经验。

这么说来，好像是，我是有些偏激了。一方面是因为第四页我的诸多回复中提到的互联网应用对服务器成本的控制。另一方面我仔细想了想，可能也是因为这么些年我的算法技能一直没有机会使用，所以总会不自觉地就希望能给自己营造出一个算法有用，算法能够带来时效的氛围。
　　在这种不自觉的自我影响中，我就越来越觉得性能问题很严重。那些动辄几百倍执行速度的都是真实数据。但我现在想，如果足够理智的话，应该仔细核算使用低效框架的服务器成本增值，和不使用框架的开发成本增值，谁更大。我以前考虑到这个问题的时候，就自己给自己应付过去了，一直没有仔细想过。

唉，我的理想啊……
　　我才做完了一个公式解析的开源小项目，本来正准备做一个内存数据中心（高可用）的开源项目，来解决我这边网络游戏排名能够实现即时排名而不像绝大多数网友得定期刷新的问题。现在看来要仔细核算一下用 MemoryCache 还是自己开发了……

虽然很沮丧，不过，还是谢谢您……

SSH 缺点并不一样，我只提到了一个共同的缺点，就是执行速度低。

那么，这个问题什么时候才严重呢？就是执行速度对整个系统比较重要的时候。

对于服务器运算资源冗余的应用场景，框架还是低速，但不会影响到系统执行结果。那就无所谓。
如果服务器运算资源紧张，集群规模比较小但用户数量很大，那就是不该使用。

当然，很多公司即便是运算资源紧张，依然使用大量的框架，这有几个原因。
1、爪哇（Java）开发人员过分熟悉使用框架，以至于很多人，嗯，绝大多数爪哇（Java）从业者没有能力脱离框架编写大规模应用。
2、研发耗时。互联网应用国内的行情（我怀疑国际上也是），目前都注重快出产品。这目的是利用创意抢用户。所以研发耗时低，就算可能得不偿失，可能服务器硬件成本会变得极高，只要用户体验别太差，最终就会用这种速成方案。当然，这也就造就了技术积累缓慢。
3、理念都是在不断更新的。比如早年认为用文本文件配置就是灵活的，后来认为用标注标明就已经灵活了，到现在认为“约定优于明示”才是更有效的。说实话，SSH 作为成熟框架，都已经有些显露出落后的疲态了。关于这个，可以关注一下 Python 这门语言。然而，程序员们，技术更新是能够很快，但理念更新并不是那么容易的，得多否定自己。这个，大家都做不够好。
4、公司的项目是长久以来继承下来的，谁也承担不起重构的风险。也不觉得重构是一个意义很大的事情。当然了，其实很可能会回归第 1 点，也就是就算重构还是会选用框架，顶多就是找找谁相对更好用。这是爪哇（Java）程序员的开发模式。

可能是会没有然后了。不过这些内容也都是在使用中体会出来的。
我想，如果一个应届生这么跟我回答，我就会问，你怎么知道的。听ta接下来咋说。不然岂不是对这个面试的人很不负责任？

我刚参加工作的时候，SSH 中，对 Hibernate 和 Struts 的机理很了解，自己都做过类似的东西，但是咋配置说实话并不太清楚，因为我从那个时候就不想用这些……（我真愧对我的学校）。Spring3 是后来因为一个项目的原因，认真看过源代码的（部分）。
　　我一直在找算法的岗位，一直没有；也竟然就这么一直在做应用了这么些年。不过幸好在自己的坚持下，现在我这边几乎所有东西都能够走出产品化的路线。这样工作还能有点继承性……

话说，我的回答中，没有提到我是应届生啊……为什么很多人都觉得我是应届生……    T T

说实话，我是考虑过汇编的。但不用汇编的理由有二个
1、我不会。这是实情。而且掌趣科技这边一个会的也没有……   T T    我以前约了一个测试的朋友一起学，但是因为各自工作繁忙，以及异地，都没有学成。吐槽一下我的毅力……太差了。
2、服务器硬件 CPU 的问题。因为现在硬件不归我自己的部门负责，受到一些因素影响，造成拿到的服务器完全无法统一规格，也无法保证支持的指令集一致。无法用汇编写通用的本地方法。

在之前，我会用 C 语言做一些最核心的方法，生成 .dll ，映射成 native 方法来使用。
但是在掌趣科技这边，我在推广全部服务器 虚拟化 ，而且不准备使用 Windows 服务器，全部用了当时新版的 CentOS 6.1 。而我又不知道 Linux C 怎么和 Java 绑定。所以这边的事情也放下来了。

其实 Java 的执行效率是非常高的。如果你愿意来我的日志看看，前几篇有一个是我为字符串处理写了几个比系统类库快很多倍的方法。但是这种个位数倍数的速度差，都是小事情。本帖第四页回复，我写了之前对反射的性能测试数据。动辄几百倍啊……如果需要服务器性能，这还是应该避免一些的。
　　不使用传统三大框架，这不是想当然，虽然可能有我想做算法的因素含在里边。但至少并不是一个太不理智的选择。

嗯。我这边没有预算用 WebLogic ，于是一直在用 Tomcat 搭建的集群。
系统因为是大游戏公司的游戏服务器，所以考虑到 Tomcat 里边 Servlet 识别的机制，这边包括 Servlet 分发都是自己做的。不过努力终究没有白费，我这边普通测试环境 Tomcat 一台可以支持弱联网用户 10000+ 同时在线了。

是的是的，欢迎大家指正。  :-)
　　不过其实我个人更希望大家去看看我那篇关于字符串处理方法的帖子，来告诉我什么地方还可以编的更好……

测试方法和结果，请参看第四页回复我的那些帖子……