-
在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有了很大提升,建议升级。