|
|
51CTO旗下网站
|
|
移步端
  • 挨踢部落故事汇(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
  • 开发者故事
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    16招轻松掌握PPT技术

    16招轻松掌握PPT技术

    GET职场加薪技能
    共16章 | 晒书包

    289人口订阅学习

    20个局域网建设改造老

    20个局域网建设改造老

    网络搭建技巧
    共20章 | 捷哥CCIE

    645人口订阅学习

    WOT2019大地必发娱乐手机版技术博览会

    WOT2019大地必发娱乐手机版技术博览会

    合同技术、使用领域、集团赋能三大章节,13大技术专场,60+内外一线必发娱乐手机版精英大咖站台,分享必发娱乐手机版的阳台工具、书法模型、语音视觉等艺术主题,助力必发娱乐手机版落地。
    共50章 | WOT碰头会

    0人口订阅学习

    读 书 +更多

    Silverlight老导学

    资本书介绍跨平台与跨浏览器的客户端技术Silverlight的采取方式。重点内容包括Silverlight效益概述与执行、探索Silverlight硬件、事件与交互...

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO播客

    
       
       
       
       

    &lt;source id="5fef8693"&gt;&lt;/source&gt;