中国领先的IT技术网站
|
|

挨踢部落故事汇(32): Java深坑如何填?

世上本没有坑,踩的人多了也便成了坑。每遇到一次困难,每踩一个坑,对程序员来说都是一笔财富。持续学习是程序员保持竞争力的源泉。本期将分享一个踩坑无数的Java程序猿填坑秘籍。

作者:51CTO开发者交流群来源:51CTO|2017-11-28 14:15


【51CTO.com原创稿件】世上本没有坑,踩的人多了也便成了坑。每遇到一次困难,每踩一个坑,对程序员来说都是一笔财富。持续学习是程序员保持竞争力的源泉。本期将分享一个踩坑无数的Java程序猿填坑秘籍。

榆木,一个阅历无数(踩坑)的技术宅男,喜欢了解新技术却不爱太钻研新技术(因为懒,猿届反面角色一枚)。14年毕业至今,在Java开发这条道路上可谓是坑过好些人、也埋过好些坑、也被坑过好些次。因为懒,没有针对他遇到过的问题做过太多的笔记(记录一些棘手问题的解决方法还是个不错的习惯),只是习惯性的去分析为什么出现这样的问题,我们该怎么去避免重复出现。在这里榆木share一下第一次做独立需求的过程。

榆木·Java开发工程师

榆木·Java开发工程师

要成为一个合格的Java程序猿,独立完成需求是一个必须经历的阶段,在这个过程中可能会遇到很多问题,要学会合理的利用资源(官方文档、社区论坛等)去解决问题。在这个阶段应该是踩坑最多、收获最多、成长最快的阶段。

在榆木入职的前3个月里,做的都是一些改bug、完善需求的活,他不需要太多思考,根据客户说的做就成了。三个月之后他的公司顺利拿下了该客户的二期项目,由于人手不够,再加上他在一期维护的时候对业务比较熟悉,老大便让榆木独自承担该项目前置子系统的全部需求。刚开始的时候榆木是很激动的,随之而来的却是不知所措。

榆木都是如何踩坑又填坑的呢?分享一下他的几点经验,希望对开发者有所帮助。

如何同时开启两个SVN服务

因为公司资源不够,老大就要求在原有的服务器上再弄一个SVN服务,于是他开始各种捣腾,可是不管怎么样就是没有办法同时起来两个服务。怎么办,只能找哥哥(google)帮忙咯,因为SVN服务的启动(/etc/init.d/svnserve start )是包含一些默认参数,如 --listen-port指定服务端口 默认是3691,如果要同时起两个SVN服务只需要在启动时指定两个不同的listen-port就OK了。

如下,问题解决:

  1. /etc/init.d/svnserve start   -d -r /svn/repo  第一次第一个库启动  默认3691 
  2. /etc/init.d/svnserve --listen-port 9999 -d -r /svn/svndata  第二次指定端口启动 

问题搞定,紧接着就是紧张的代码开发,事情有点想不到的顺利,后端接口顺利完工通过测试,榆木开始和前端对接联调,好激动,搞不好可以提前完成任务了。噼里啪啦的搞完就开始测试了。

fastJson序列化问题

所谓没有遇到过bug的程序猿就不是正常的程序猿,一点都不意外,问题来了。同一个对象赋值给HashMap中不同的key 传到前端后,第二个value竟然不能被正常解析....... 他自己写的代码必须不能怂,有问题那就解决问题,于是榆木开始找问题所在,开始模拟数据,发现返回结果如下:

  1. {"o1":{"age":16,"name":"o1"},"2":{"$ref":"$.o1"}}  

很容易就能看出来,第二value在这个返回结果中用类似指针的方法("$ref":"$.o1")表示它和“o1”的值一样,看起来像是同一个对象的循环引用哦,那是不是可以把这个循环引用禁止呢?答案是可以的。(有必要说明一下,这里使用的是fastJson)通过SerializerFeature指定禁用循环依赖就可以了。修改前代码如下:

  1. public static void test1() { 
  2.         TestObject object = new TestObject("o1", 16); 
  3.         Map<String, TestObject> map = new HashMap<String, TestObject>(); 
  4.         map.put("o1", object); 
  5.         map.put("o2", object); 
  6.         System.out.println(new String(JSON.toJSONBytes(map))); 
  7.     }        

输出结果:{"o1":{"age":16,"name":"o1"},"o2":{"$ref":"$.o1"}}

在一个集合对象中存在多条相同数据时,将ist集合对象转化为json对象输出到前台时,JSON默认对第二条数据处理时用"$ref":"$.object".<这里object指第一条数据>,这样的json转化结果输出到前台肯定是不可以使用的,好在JSON有提供禁止关闭引用循环检测的方法,只需要在转化的时候加上SerializerFeature.DisableCircularReferenceDetect  就可以解决了。修改后代码如下:

  1. public static void test1() { 
  2.        TestObject object = new TestObject("s1", 16); 
  3.        Map<String, TestObject> map = new HashMap<String, TestObject>(); 
  4.        map.put("o1", object); 
  5.        map.put("o2", object); 
  6.        SerializerFeature feature = SerializerFeature.DisableCircularReferenceDetect; 
  7.        System.out.println(new String(JSON.toJSONBytes(map, feature))); 
  8.    } 

输出结果如下:{"o1":{"age":16,"name":"o1"},"o2":{"age":16,"name":"o1"}}

到这里问题就解决了。不久之后测试通过了,交付客户测试版本,开始和中心联调测试了。

OOM异常处理

榆木以为到这里就万事大吉了,然而是不可能的。联调测试两天之后,客户反馈说:“我们的XXX报文数据已经往中心发过了呀,可是中心说他们没有收到,你们查下是什么问题呗!”客户就是上帝呀,榆木和他的同事开始查询日志,发现有一些OOM的异常。异常产生的场景是在取数据-组报文-MQ转发这个环节,然后就开始一个一个点的排查了。

榆木首先想到的可能原因有:

1、数据取出来生成报文这个过程都是在内存中做的,会不会是这里数据太多导致?

2、会不会是报文生成过程产生了过多Object没有来得及回收?

3、会不会是数据发送慢于报文生成的速到导致等待队列爆满?

然后开始针对性的做修改测试,他将一次性取数据生成报文的过程改成批量去做,然后测试运行一段时间没有问题(排除 1);在生成保温过程中,将每一个转化后的对象置为空Object=null,以便及时回收,测试运行一段时间没有问题(排除2);在第三点上面,他最先想的是增加线程数量( 服务器开启超线程、应用中增加线程数量)去提升处理速率,运行一段时间之后还是会出现OOM。怎么办呢?再次回到了等待队列上面来,能不能在一定程度上对等待队列做个限制呢?于是榆木在每次从MQ取消息之前增加了对等待队列的深度的判断,如果深度大于最大线程数量的2倍,就放弃本次MQ队列消息的处理。然后继续测试,问题没有再出现。

查询慢怎么办?

最终项目上线了,终于可以松一口气了。可是有一天,榆木的老大说客户反映部分查询很慢,让他去处理一下。榆木心里想着,这个应该是个小问题,给数据表加索引就能搞定。到了客户现场之后发现,原来的表是有索引的,可查询还是慢,不得已只能去找原因了。不得不说,explain SQL是个不错的命令,发现索引没有生效,经过仔细的比对,发现该关联查询的关联字段在两个表中都有索引, 两个表的字符集都是UTF8,但是排序规则一个是utf-bin(二进制存储数据,大小写区分),一个是utf8_general_ci(大小写不敏感),所以把数据排序规则改成一致索引生效,查询速度也就上来了。

PS: mysql中的UTF-8编码的排序规则说明

utf8_bin将字符串中的每一个字符用二进制数据存储,区分大小写。

utf8_genera_ci不区分大小写,ci为case insensitive的缩写,即大小写不敏感。

utf8_general_cs区分大小写,cs为case sensitive的缩写,即大小写敏感。

【写在最后】

榆木整理了下这些年踩的坑,给自己也给正在和他挣扎在挨踢坑里的小伙伴们一些启发与鼓励。持续学习是保持竞争力的前提;夯实的基础是进阶的垫脚石。抬头走不独行(exchange)、埋头干(code),就算被称作屌丝,也还是要有梦想,万一逆袭了呢。

 如果你也愿意分享你的故事,请加51CTO开发者QQ交流群 114915964联系群主小官,期待你精彩的故事!

51CTO开发者交流群⑥群114915964

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【编辑推荐】

  1. 挨踢部落故事汇(27):邻家运维工程师的成长日记
  2. 挨踢部落故事汇(28):梦醒在Java进阶处
  3. 挨踢部落故事汇(29):开发转型测试是一种怎样的体验
  4. 挨踢部落故事汇(30):我与Python的相爱相杀
  5. 挨踢部落故事汇(31):一名合格的网络工程师是如何炼成的?
【责任编辑:何星 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

征服Python—语言基础与典型应用

Python是目前流行的脚本语言之一。本书由浅入深、循序渐进地讲解如何使用Python进行程序开发。全书内容包括Python安装、开发工具简介、Pyth...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊