- 在Spring项目中，如果需要配置spring xml文件，要注意，将顶部的schema信息中的版本信息去掉，这样xml配置文件就不会跟具体的spring版本耦合；而且还可以避免一些诡异的问题，例如下面这种异常
org.xml.sax.SAXParseException :schema_reference.4: 无法读取方案文档 'http://www.springframework.org/schema/beans/spring-beans-3.0.xsd', 原因为 1) 无法找到文档; 2) 无法读取文档; 3) 文档的根元素不是 <xsd:schema>。这种错误的原因是：spring xml配置文件中指定的xsd文件读取不到了，原因多是因为断网或spring的官网暂时无法连接导致的。
参考：Spring如何加载XSD文件(org.xml.sax.SAXParseException: Failed to read schema document错误的解决方法) - 在Spring + MyBatis项目中，写SQL语句的时候，要注意返回null的情况，例如：
<select id="getFileSize" resultType="Long"> SELECT sum(file_size) as fileSize FROM file_nodes WHERE uid=#{uid} </select>上述SQL语句，有可能返回null，因此resultType必须用Long，且Dao层的返回值也要用Long，并且需要在调用方做出判断和处理，否则会报空指针错误。
- awk，用于日志分析和数据统计。例如，最近有个数据统计的需求，那么命令
awk -F '[:,]' '{s[$4] += $6; a[$4] += $8}END{for(i in s){print i, s[i], a[i]}}' OFS="\t" odsToolResBak可完成的工作是：将一个json字符串组成的日志文件，按照冒号和分号切割，并按照第4列分组，分别求第6列和第8列的和，最后每行的结果直接用'\t'分割。参考资料如下： - vim，另一个上古神器，要熟悉常用的命令，例如
10,100w!>>test.txt，该命令可将10行到100行的内容复制到另一个文件test.txt中；参考资料如下： - 分享一个匹配中国大陆的有效手机号码的正则表达式：点我。另外，使用Java进行正则匹配的教程，可以参考：Java正则表达式
- Thymeleaf是一种用于代替JSP的新兴技术，Spring提供了与Thymeleaf的原生模板（nature template）协作的视图解析器。Thymeleaf与Velocity不同的地方在于，它看起来就像是原生的Html页面，不过在Html标签中增加了访问Spring bean的功能，并且可以直接在浏览器中打开。一言以蔽之：页面即原型。关于Thymeleaf的介绍可以参看这篇文章：新一代Java模板引擎Thymeleaf
- 别返回null值：当一个方法返回Collection集合的时候，不要返回null，如果没有结果则返回空的集合（例如：Collections.emptyList();），这样该方法的客户就不需要判断null的逻辑。这就是Java开发中的特例模式的应用。
- 如何学习开源项目，例如Spring？接触Spring近一年了，零零碎碎看了很多资料，看得阅读，就能将越多零碎的知识点拼接在一起，对Spring的整体设计思路也有渐渐加深的体会。整理一点优质材料在这里吧：
- 好书
- 《Spring揭秘》，关于Spring的技术图书，这本最好，具体怎么好？读了就知道，喜欢探究原理的人读起来一气呵成，很hi；
- 《Spring实战 第4版》，最近国内刚出中文版，这本书的特点就是：知识点整理清楚，例子完整。虽然少了点原理讲解，比较适合Spring入门；
- 《Spring技术内幕》，这本书去年浏览过一次，对代码的走读不错，但是有些原理性、设计思想阐述得不够深刻；
- 好文
- 我为什么要做瞎子摸象的践行者，文中的“如果一个事物庞大到你无法一眼就看透它，了解它， 那么， 不妨先一小块儿一小块儿的去探索，然后再结合你探索的这些碎片成果进行拼装和推演， 慢慢地，你就会对这个庞然大物有了更多的了解（当然， 是否能够完全了解，我就不敢妄言了）”这句，非常适合用在这里。spring发展到现在的4.3，已经非常复杂且包含了太多内容，我们不可能一上来就掌握全局，只能一点一点去看。
- Spring框架的设计理念和设计模式分析
- 好书
- 今天遇到一个应用启动失败的例子，一直处在tomcat wait的状态，查了很多问题没发现原因，最后才想到要看线程堆栈，用命令
jstack pid >> temp.123将线程堆栈dump到文件中，发现某个bean初始化的时候依赖了第三方服务，而部署的机器跟那个服务属于两个独立环境，因此线程在这里Hold住了。- 当发现应用表现为性能低下、启动卡主时，要使用jstack看线程堆栈；
- 当发现应用表现为内存gc异常，要使用jstat查看内存使用情况
- 今天对应用做性能测试的时候，发现CPU一直打满，由于该应用中大量应用了异步任务，怀疑是线程太多导致的CPU争用。根据关于JVM CPU资源占用过高的问题排查一文的提示，首先通过
top命令，获得JVM进程的PID；然后用命令top -H -p PID，获得JVM中各个线程的运行情况，可以看到某些进程消耗的CPU一直在90多，记录这些线程的thread id，并转成十六进制；然后用命令jstack -l PID >> temp.123将JVM的运行栈打印到文件中，然后利用上述的十六进制thread_id在文件中查找，就可以看该线程的CPU都消耗在哪里了。
通过抓堆栈发现，那些占用CPU比例过高的线程都是http处理线程：要不就是在等待请求到来；要不就是在处理一个JSON字符串——String responseContent = JSON.toJSONString(retResponse);，然后我们把这个retResponse打印出来一看，NND，这个对象得有1kb大小，好的，那就是这个东西占用了大量的CPU时间！ - 在性能问题上，有两个低级问题首先要排除：（1）大对象的json序列化；（2）日志级别要调到warn级别，不能在debug级别上进行压测。
- 最新的版本：fastjson 1.2.11版本，据说性能比1.1有了很大提升，建议升级。
时间： 2024-10-27 09:09:51