常见技术架构优缺点分析
1. spring 优缺点分析
- 难以调试
- 配置文件方面，增加了额外的开发和维护工作。
- 程序的逻辑性和可读性确实降低
- 使用引入了新的复杂度,小型项目引入Spring简直是噩梦
- 4，感觉引入了Spring的项目，很难从Spring中脱离出来，我认为Spring对项目的耦合太过紧密，就像一个强有力的皮搋子吸住马桶口不放开。
这点严重同意，神马“非侵入框架”，都是骗人的，不说别的，你就光把你项目中的配置文件全换一遍试试？配置文件这玩意儿，多了也算是侵入，我曾经所在的某个项目，各种配置文件加起来的维护难度，已经大大超过代码了。代码起码还有eclipse里面F3跳来跳去，再不行还能debug。- 开发效率。Spring这种通过XML配置的方式，很容易配置错误，影响开发效率。当然有些配置可以使用Anotation配置，但是不能完全替代XML，比如包扫描，创建多个实例都需要通过XML来配置。Spring的这种设计是一种通过XML来编程的方式。
- 测试效率。配置多的话，容器启动时间比较长，影响测试效率。所有有些测试，我们尽量都不启动Spring容器。
- 有一定的上手成本。
2 druid的优缺点
- 监控强大
- 日志打印
3 mybatis 和hibernate的对比
MyBatis在Session方面和Hibernate的Session生命周期是一致的，同样需要合理的Session管理机制。MyBatis同样具有二级缓存机制。 MyBatis可以进行详细的SQL优化设计。
- SQL优化方面
Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的，所以可以按需求指定查询的字段。- 扩展性方面
Hibernate与具体数据库的关联只需在XML文件中配置即可，所有的HQL语句与具体使用的数据库无关，移植性很好。MyBatis项目中所有的SQL语句都是依赖所用的数据库的，所以不同数据库类型的支持不好。- 优势对比
Mybatis优势
MyBatis可以进行更为细致的SQL优化，可以减少查询字段。
MyBatis容易掌握，而Hibernate门槛较高。
Hibernate优势
Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。
Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。
Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。
Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。
测试结果：
总体初观，myBatis在所有情况下，特别是插入与单表查询，都会微微优于hibernate。不过差异情况并不明显，可以基本忽略差异。
差异比较大的是关联查询时，hibernate为了保证POJO的数据完整性，需要将关联的数据加载，需要额外地查询更多的数据。这里hibernate并没有提供相应的灵活性。
关联时一个差异比较大的地方则是懒加载特性。其中hibernate可以特别地利用POJO完整性来进行缓存，可以在一级与二级缓存上保存对象，如果对单一个对象查询比较多的话，会有很明显的性能效益。
以后关于单对象关联时，可以通过懒加载加二级缓存的方式来提升性能。
最后，数据查询的性能与orm框架关无太大的关系，因为orm主要帮助开发人员将关系数据转化成对象型数据模型，对代码的深析上来看，hibernate设计得比较重量级，对开发来说可以算是重新开发了一个数据库，不让开发去过多关心数据库的特性，直接在hibernate基础上进行开发，执行上分为了sql生成，数据封装等过程，这里花了大量的时间。然而myBatis则比直接，主要是做关联与输出字段之间的一个映射。其中sql基本是已经写好，直接做替换则可，不需要像hibernate那样去动态生成整条sql语句。
好在hibernate在这阶段已经优化得比较好，没有比myBatis在性能上差异太多，但是在开发效率上，可扩展性上相对myBatis来说好太多。
4. nosql 关系型数据库对比
4.1 NOSQL的优势
1易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
2. 大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
3. 灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
4. 高可用
NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
总结
NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。
5 mongodb 适用场景和不适用场景
mongo使用场合
mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：
- 网站数据:
mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。- 缓存：
由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。- 大尺寸、低价值的数据：
使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。- 高伸缩性的场景(nosql就是为集群而生)：
mongo非常适合由数十或者数百台服务器组成的数据库。- 用于对象及JSON数据的存储：
mongo的BSON数据格式非常适合文档格式化的存储及查询。
不适合的场景：
- 高度事务性的系统：MongoDB 不支持事务。例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
- 传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
- 需要SQL的问题。
5. jetty、 tomcat比较
都遵循Java Servlet规范
- Jetty更轻量级。这是相对Tomcat而言的。
由于Tomcat除了遵循Java Servlet规范之外，自身还扩展了大量JEE特性以满足企业级应用的需求，所以Tomcat是较重量级的，而且配置较Jetty亦复杂许多。但对于大量普通互联网应用而言，并不需要用到Tomcat其他高级特性，所以在这种情况下，使用Tomcat是很浪费资源的。这种劣势放在分布式环境下，更是明显。换成Jetty，每个应用服务器省下那几兆内存，对于大的分布式环境则是节省大量资源。而且，Jetty的轻量级也使其在处理高并发细粒度请求的场景下显得更快速高效。
- Jetty更灵活，体现在其可插拔性和可扩展性，更易于开发者对Jetty本身进行二次开发，定制一个适合自身需求的Web Server。
相比之下，重量级的Tomcat原本便支持过多特性，要对其瘦身的成本远大于丰富Jetty的成本。用自己的理解，即增肥容易减肥难。
- 然而，当支持大规模企业级应用时，Jetty也许便需要扩展，在这场景下Tomcat便是更优的。
总结：
Jetty更满足公有云的分布式环境的需求，而Tomcat更符合企业级环境。
GAE放弃了Tomcat，选择了Jetty，正是因为Jetty的体积和灵活性，Google可以更好地定制一个足够小的Java Web Server为其GAE服务。
而Tomcat为满足更多的企业级需求，增加了JEE特性，在服务企业级应用时，它的支持优于Jetty。然而，即使Tomcat性能略优于Jetty，但对于大多非企业级应用而言，配置复杂体积庞大的Tomcat显得过于重量级。
正因为这个，实验室的云平台实现便是把云平台本身的门户网站放在Tomcat内，而云台托管的Java Web应该是部署在Jetty内的。
6. Servlet是线程安全的吗
servlet是线程安全的吗
- servlet里的实例变量，是被所有线程共享的,所以是线程不安全的.
- servlet方法里的局部变量
因为每个线程都有它自己的堆栈空间,方法内局部变量存储在这个线程堆栈空间内,
且参数传入方法是按传值volue copy的方式
所以是线程安全的
局部变量指的是字段和共享数据，主要是表单的参数值
ServletContext：（线程是不安全的）
HttpSession：（线程是不安全的）
ServletRequest：（线程是安全的）