帐前卒专栏

code, software architect, articles and novels.
代码，软件架构，博客和小说

Posted on Edited on Word count in article: 660 Reading time ≈ 1 mins.

最近几天看了引爆点这本书。觉得不错，所以谢谢总结。

1. 引爆点中讲到三种人：内行，推销员，联系员。

2. 然后是引爆点本身的属性：附着力

3. 最后是引爆点的环境

内行：就是砖家，叫兽。整天这也倒腾，那也参与。对某些事情特专，你非常相信他们的话。或者新闻联播非常相信他们的话。

推销员：就是传播者。就是整天没事唠嗑，在各种群里、微博里、微信朋友圈里整天八卦、爱传图、爱发小道消息。今天10条佛教真理，明天10条人生必看，后天10条xx必读。

联系员：就是你的大多数非学生时代的朋友，非同事关系的朋友都是他介绍的。一般找他打听个人是没有问题的，他会瞬间把那人的手机名片家庭住址都给你。接触过非常多的人，微信朋友，QQ朋友,人人校友啥的都暴表了。想起我一师兄，人人多个帐号，每个帐号都加满了3000个女同学。

附着力：这个是引爆点的本质属性。也就是说，如果某件事情，你觉得好玩，好笑，非常有意思，那这件事对你而言就有很强的附着力。例如，酒对于酒鬼；烟对于烟鬼；水对于水鬼。

最后是环境：这个环境，是一种风气。环境将在特定的时期，特定的地点对特殊的一堆人产生的影响。比如鸭梨山大的社会就喜欢马舞和狐狸叫；破窗环境；涂鸦环境；而在环境中影响出来的人，又会存在内行、推销员、联系人三种人，这三种人又会扩大环境，这样层层扩散，就形成了流行。

这本书的总结就到这里了。没有啥可以被实践的。感觉自己身边这三种人都有，不过我发微博，对他们来说都没有任何附着力，所以什么时候发都行不成潮流。不知道在我把这书的内容全部遗忘之前能不能使用一次。

另外，感谢一下二师兄…

Posted on Edited on Word count in article: 224 Reading time ≈ 1 mins.

昨天，同事发现一个这样的问题：java.lang.OutOfMemoryError: unable to create new native thread。发现heap内存还是充足的情况下，free memory还是充足的情况下，thread分配不了了。这个问题在于线程的数量 = (jvm进程内存 - jvm heap size) / 线程stack size.   所以这里解决的办法就是 增加 jvm进程内存，减少Jvm heap size, 以及减少每个thread的stack size.

Posted on Edited on Word count in article: 407 Reading time ≈ 1 mins.

今天组内有人收到了 “乐云记事”的战书。战书很漂亮。好像里面还有个蛋糕，不过我没有吃到。真希望蛋糕里被下了毒~~~我也不知道我这是抱着怎样的心态在写文章。

上两个照片：

组里没有说不能把图贴出来…所以我就贴一下吧。我想乐云记事也是希望大家知道的。否则下个战书干啥？以后要送蛋糕送大点呀！然后组里的人们都开始关注“乐云记事”这个应用了。才发现原来这货很久前就出来了。只是一直没有到达我们的耳朵。好吧，现在宣传一下。

不过话说回来，我并不是有道云笔记的发言人。所以我也不是应战书的。我只是抱怨一下蛋糕没有吃到。

另外今天上午看了一下 HDIV这个东西。发现真心不错。下次推荐大家使用一下。

顺便看了一下360的年终奖，真是有钱人呀。等我去了360…那奖也不一定是我的。现在回想当年在实验室的生活，还是不错的。使用一个词总结一下：不患寡而患不均。

下午要给大家讲一个ppt， ppt的具体内容我现在还没有理解。嗯，到时候大家一起理解好了。

Posted on Edited on Word count in article: 785 Reading time ≈ 1 mins.

昨天遇到一个问题，请求发送之后直接返回了500错误，没有过ErrorController。并且Server这边的log里也没有异常。这真的是好奇怪。

产生问题的method是这样写的：

1
2
3
4
5
6
7
8
9
10
11

   @RequestMapping(params = "method=bulkChange", method = RequestMethod.POST)
    public @ResponseBody
    User changePhoto(
                            @RequestParam(value = DESCRIPTION_NAME, required = false, defaultValue = DESCRIPTION_DEFAULT)
                            String description,
                            @RequestParam(value= PHOTO_NAME, required = false, defaultValue = PHOTO_DEFAULT)
                            MultipartFile photo,

                            HttpServletRequest request, HttpServletResponse response) throws Exception{
}

这出问题的地方就在于photo这个参数。如果将这个参数注释掉，一定没有问题。那这里在上传图片时，不会有500错误。但是在上传不含图片的时候，就会有500错误了。这是为啥米？看起来问题应该是required=false时，没有上传参数，直接使用了defaultValue.而我这里的defaultValue是个空字符串就直接挂了。应该使用ValueConstants.DEFAULT_NONE， 或者"\n\t\t\n\t\t\n\uE000\uE001\uE002\n\t\t\t\t\n" 这个将在Spring框架里作为 null进行处理。

改好后就解决了之前的问题。

Posted on Edited on Word count in article: 1.4k Reading time ≈ 1 mins.

我个人不觉得的互联网快速试错是一件称道的事情。甚至我觉得这是一件不光彩的事情。我觉得也没有产品经理看我的blog，所以黑一黑产品经理，也是一件心情愉悦的事情。

开始推出“快速试错”的产品或者通过“快速试错”成功的产品，必然是互联网为数较少的几个。甚至是互联网初期阶段的几个产品。因为怎么试都是一条好路，提前抢占市场才是重要的。但是互联网发展到现在，再提“快速试错”那就大错特错。因为消磨了时间、金钱、精力、激情，甚至机遇。如果自己觉得这个决定可能错误，那为什么不找一个更容易正确的决定呢？所以当做产品的对你说，我们快点推出产品吧，来个“快速试错”。你就要小心了。开发是生产活动中最为稀缺的资源。每个开发都不希望自己做的功能是绝大部分用户永远用不到的功能。如果产品说“快速试错”，那为什么产品经理们不拍拍脑子里进的水，仔细想想怎么做一个基本正确的产品呢？

当然，产品经理们的观点是：1. 产品未推出前，不知道用户的评价。2.产品快速出新，刷存在感。3.产品有反馈，可以更好的改进。

以上三点，貌似是产品经理的盾牌，实际上是薄薄的纸壳。

1. 功能的开发其实完全可以不做的。只需要能做出来让用户觉得是否好用的原型就行。如果产品的定位用户是码农，就首先先听听码农自己们的意见。（给产品经理说句丧气话，基本上互联网上的新产品都是针对码农的。因为非码农也搜索不到你的产品。）码农自己觉得功能不错，那就放心大胆的做。码农自己都觉得这东西根本不会用，那就劝产品经理们三思。如果做出来的demo，连码农自己都觉得别扭，那还是不要推广了。自己心满意足的做做白日梦就可以了。

2. 快速出新是好事，但是快速意味着功能少，改动少，测试不全面。带来的问题总之多多，每次用户更新都是要费时间的。举个例子，Adobe的flash更新。每次都更新，也不知道到底更新了什么了。而且bug fix一轮又一轮，感觉每隔几天提醒一次flash更新。当然Adobe的更新大部分是安全问题，所以还是必须更新的。当你的产品没有做到Adobe的用户量时，那就不要学adobe更新速度。

3. 产品反馈是好事，如果不是烂产品，大家都是带着鼓励加上自己的意见。不过一旦产品选错了路，很难想象用户能纠正，大部分用户都是顺着这条错路给你产品意见的。嗯，你觉得顺着错路做出来的产品再推出时能好用？比如说，手电筒应用。用户提意见：可以做一个应用平台呀，用户量都这么大了。如果手电筒应用做了应用平台，大家又会建议：这个应用平台不能只下应用呀，还要有推荐、有评价、有社交功能。 看客是否觉得这产品该叫豌豆荚了？我个人觉得不要太听用户的意见。虽然用户都是好心。但是嗓门大的那些用户可能并不是你的目标用户。而你的目标用户可能还没有下载你的应用呢。不要认为下载并且评价你的应用的用户就是目标用户。请告诉我，乔布斯是每次听取大家的意见，然后做手机的吗?那他应该做一个防水防尘防摔的山寨nokia呀！而且你看，每次大家都抱怨，iphone不防水不防尘不防摔，为什么他就是不改改呢？人家乔布斯知道真正的目标用户是谁，屌丝手机肯定不是他老人家考虑的范围。

SO，广大的开发者们，当产品经理对你说，咱们做个cool功能吧；当产品经理对你说，咱们来个“快速试错”吧；当产品经理对你说，用户是这样反馈的；开发者呀，你们眼睛要雪亮雪亮的，让这些产品经理先一边拨弄原型自己玩去。

Posted on Edited on Word count in article: 2.1k Reading time ≈ 2 mins.

小卒 最近在做头像上传功能，发现对于带有alpha通道的图片，有的会变红，有的会变黑，有时压缩不平滑。发现是有几处程序写错了。

首先贴一下原始的程序，这段程序的功能是将原图的(x,y,w,h)图块，转变为 (0,0,targetW,targetH)图片，并输出为jpg格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

private byte[] cropAndCompressImage(int x, int y, int w, int h,
                                        BufferedImage image, int targetW, int targetH) throws Exception{
        if (w == -1 && h == -1 && image != null) {
            // use full image
            w = image.getWidth();
            h = image.getHeight();
        } 
        if (x < 0 || y < 0 || w <= 0 || h <= 0 || image == null) {
            // error
        }
        w = Math.min(x+w, image.getWidth()) - x;
        h = Math.min(y+h, image.getHeight()) - y;
        try {
            BufferedImage cropedImage = image.getSubimage(x, y, w, h);

            // do image compression
            int type = image.getType() == 0 ? BufferedImage.TRANSLUCENT
                    : image.getType();
            BufferedImage compressedImage = new BufferedImage(targetW, targetH, type);
            Graphics2D graph = compressedImage.createGraphics();
            graph.drawImage(cropedImage, 0, 0, targetW, targetH, null);
            graph.dispose();

            ByteArrayOutputStream bytes = new ByteArrayOutputStream();
            ImageIO.write(compressedImage, "jpg", bytes);

            return bytes.toByteArray();
        } catch (IOException e) {
            // error
        }
    }

首先是背景有时变黑，这里最简单的做法是将最后的背景图片设置为白色。见下面代码：

1
2
3

//graph.drawImage(cropedImage, 0, 0, targetW, targetH, null);
graph.drawImage(cropedImage, 0, 0, targetW, targetH, Color.white,null);

加一个Color.white即可。

下面要解决的是图片变红问题。 帐前卒 认为这个问题其实是alpha通道需要变为透明的。而原始程序是判断，如果
该图片是定义为Custom的图片，那么就变为透明。显然custom的图片不一定是透明图片。所以这里需要判断image是否为透明的。代码变为:

1
2
3
4
5
6
7
8
9
10

// int type = image.getType() == 0 ? BufferedImage.TRANSLUCENT
                    : image.getType();
            // BufferedImage compressedImage = new BufferedImage(targetW, targetH, type);
            BufferedImage compressedImage = null;
            if (image.isAlphaPremultiplied()) {
                compressedImage = new BufferedImage(photoType.getWidth(), photoType.getHeight(),                 BufferedImage.TRANSLUCENT);
            } else {
                compressedImage = new BufferedImage(photoType.getWidth(), photoType.getHeight(),                 BufferedImage.TYPE_INT_RGB);
            }

然后变红问题就解决了。下面是压缩图片时，发现很多地方不光滑，这里也非常好解决。帐 前卒的代码如下： ```

// graph.drawImage(cropedImage, 0, 0, targetW, targetH, null);
            // graph.drawImage(cropedImage, 0, 0, targetW, targetH, Color.white,null);
            graph.drawImage(cropedImage.getScaledInstance(targetW,  targetH,  BufferedImage.SCALE_SMOOTH), 0, 0,             Color.white,null);


加入SCALE_SMOOTH参数就完成了~~

Posted on Edited on Word count in article: 1.6k Reading time ≈ 1 mins.

有点滴剧透，没看过的误入…那就没有办法了…请增加点击率后，自动退出吧。

私人定制一共讲了五个故事。分别是“xxx”, “性本善”，“一腔俗血”，“有钱”和“道歉”。第四个故事忘记名字了，不过主题意思是道歉。而第一个故事叫什么名字，因为去的晚，没有看到。总感觉这五个故事是不连贯的，虽然反映了社会的方方面面，但是每个人物的性格表现还是太弱了。对于第一个故事不做评价，而第二个故事讥讽力度还是不够的，大多点到为止，笑看官场亦怕官。不过取名“性本善”和孟子的主张是一致的。不过如果每个人都是善的，为何有了恶的根源。突然想起了《黑镜》的第一个故事，每个人都是推波助澜的根源。让我想到集体主义和个人主义冲突的时候…为什么个人主义必须服从集体主义呢？或许是因为个人离开了集体必然会导致死亡。而牺牲了个人，似乎可以让剩余的集体生存，甚至让个人仍能存活下去。所以在生存和屈辱之间，还是毅然决然的选择生存。不过这样说似乎抹灭了先烈们的光辉事迹。嗯，牺牲个人利益的先烈们，仍然是可敬的。

对于第三个故事，一腔俗血。看起来是导演的自嘲。只有在俗中才能生存，而玩弄雅的"1942"必定是死的艺术。不过艺术是什么？是大雅之道还是大俗之路呢？突然想起《战国鬼才传》，物极必反。追求极雅，恍惚之间弄得人物皆非，是可笑的。而真正的雅，仍然在平时的生活之中。

而第四个故事“有钱”。是我和LP大人都觉得不错的故事。钱是生存之物，时间也是。导演没有说金钱乃身外之物，这么俗套的台词。而插曲却明显的表现了这一思路。这有让我想到《时间规划局》这一科幻的题材，时间等价于金钱。想法很好，可惜导演不咋地。对于有钱人的意淫，仍旧是痴人说梦。我们中的大多数都是平凡的人，暴发了几个亿的人，我觉得也不会看到我的blog。我们幻想着以后自己如何如何的有钱，然后不屑于已经有钱的各种作为。然后说一句“金钱乃身外之物，生不带来，死不带去”，自嘲式的让自己活得心安理得。而在故事中也隐隐的提及了亲情和报恩之情。

第二个故事到第四个故事，其实完全可以提高到《黑镜》第二集的高度，不过导演想到如果再高雅起来，票房就会像1942一样难看吧。人生就是一个循环，人永远不知道在为什么干活。知道干活能赚到钱这个简单的目的，从来没有想过干活最终是为谁在干活，以及干活到底是为了什么，对于这个社会而言有什么必要性？但是社会就是一个俗场，不管如何的高雅，最终都会被这社会的俗所淹没。不管人生如何的抗争过，却都会软弱的存活于社会之中。当然真正的高雅之士，真正的抗争之人，真正的正义之士都已经game over了。因为他们都被社会淘汰了。

而第五个故事“道歉”。或许是对自然难以报恩的愧疚之情。不过我和LP大人都觉得这个故事是没有必要的，在第四个故事其实影片就可以结束。而导演又开始玩点雅的，导致
大家莫名其妙。

总结一下：《时间都去哪了》 这个歌不错。来，贴一下歌词和歌的链接： http://music.baidu.com/song/14385500

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
门前老树长新芽

院里枯木又开花

半生存了好多话

藏进了满头白发

记忆中的小脚丫

肉嘟嘟的小嘴巴

一生把爱交给他

只为那一声爸妈

时间都去哪儿了

还没好好感受年轻就老了

生儿养女一辈子

满脑子都是孩子哭了笑了

时间都去哪儿了

还没好好看看你眼睛就花了

柴米油盐半辈子

转眼就只剩下满脸的皱纹了

记忆中的小脚丫

肉嘟嘟的小嘴巴

一生把爱交给他

只为那一声爸妈

时间都去哪儿了

还没好好感受年轻就老了

生儿养女一辈子

满脑子都是孩子哭了笑了

时间都去哪儿了

还没好好看看你眼睛就花了

柴米油盐半辈子

转眼就只剩下满脸的皱纹了

Posted on Edited on Word count in article: 4.4k Reading time ≈ 4 mins.

各位的用户注意一下来自CSDN的邮件 可能含有病毒。 今天上午收到一封来自CSDN的邮件。

标题引起了我的注意。并且它还带有一个附件。没有正文内容。查看了一下信头

1
2
3
4
5
6
7
8
Received: from csdn.net (unknown [218.93.225.174])
	by mx3 (Coremail) with SMTP id NcCowEC5+mIspLJSghUHAQ--.1389S2;
	Thu, 19 Dec 2013 15:45:50 +0800 (CST)
From: [email protected]
To: --
Subject: nyboealdzx
Date: Thu, 19 Dec 2013 15:46:39 +0800
MIME-Version: 1.0

这个看起来是从csdn.net那个域发送过来的。不过unknown意味着没有进行签名。后来觉得是不是CSDN的邮件都是这样的？然后查看了之前几个CSDN邮件的信头：

这个是邀我参加开源中国的邀请邮件：

1
2
3
4
5
6
7
8
9
10
Received: from mx151.csdn.net (unknown [124.193.87.153])
	by mx49 (Coremail) with SMTP id Y8CowEApI079esJR1SMTCw--.1499S2;
	Thu, 20 Jun 2013 11:46:05 +0800 (CST)
Received: by mx151.csdn.net (Postfix, from userid 0)
	id 99C7E40A18; Thu, 20 Jun 2013 11:39:21 +0800 (CST)
Content-Type: multipart/mixed; boundary="===============2088245834=="
MIME-Version: 1.0
Subject: =?GB2312?B?Q1NETsnnx/izz9H7xPqyzrzTILXasMu97KGwv6rUtNbQufq/qtS0ysC956GxuN+35cLbzLM=?=
From: CSDN<[email protected]>
To: --

这个看起来是一个csdn的子域发送过来的。然后查看了另外一个csdn的邮件，这个是赠送图书的。这封信来自于mail.csdn.net, 但是真实发出的是

1
gaoshan-PC (unknown [192.168.4.111])

下面是详细内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Received: from mail.csdn.net (unknown [211.103.135.164])
	by mx18 (Coremail) with SMTP id RMCowECpvUNu1uhRmXtoAQ--.527S2;
	Fri, 19 Jul 2013 14:02:22 +0800 (CST)
Received: from localhost (localhost.mail.csdn.net [127.0.0.1])
	by mail.csdn.net (EMOS V1.5 (Postfix)) with ESMTP id 258322A18013;
	Fri, 19 Jul 2013 13:52:23 +0800 (CST)
X-Virus-Scanned: amavisd-new at csdn.net
Received: from mail.csdn.net ([127.0.0.1])
	by localhost (mail.csdn.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id rSjhuVYKv6Ko; Fri, 19 Jul 2013 13:52:22 +0800 (CST)
Received: from gaoshan-PC (unknown [192.168.4.111])
	by mail.csdn.net (EMOS V1.5 (Postfix)) with ESMTPA id B01A967E0582;
	Fri, 19 Jul 2013 13:52:22 +0800 (CST)
Date: Fri, 19 Jul 2013 14:02:21 +0800
From: admin <[email protected]>
Reply-To: admin <[email protected]>
Subject: =?gb2312?B?Q1NETtH7xPqyzrzTobDQtMrpxsC1w7y8yvXNvMrp067PwtTYt9ahsbKpv83XqLzSoaKw5tb316jK9Lvutq8=?=
Disposition-Notification-To: admin <[email protected]>

另外我怀着好奇心，查看一下其他邮箱从QQ那边发来邮件。注意其中含有DKIM签名。这个是验证域用的。里面可以看到来自qq.com。这就可以放心，这封邮件至少不是伪造的。但是很可惜，这里签名用错了。

Received: from smtpbg15.qq.com (unknown [183.60.61.204])
	by mx45 (Coremail) with SMTP id X8CowEB5TGDld7FRy8pfBQ--.918S2;
	Fri, 07 Jun 2013 14:04:21 +0800 (CST)

虽然下面是qq域的DKIM签名，但是上面还是显示unknown， 这是因为DKIM签名的域是qq.com但是发送的域是smtpbg15.qq.com

1
2
3
4
5
6
7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1370585061; bh=vXVivKNEwifo2iLclSc6hbMDASAhfzVUi+Zil5icxDU=;
	h=X-QQ-STYLE:From:To:Subject:Message-ID:Mime-Version:Content-Type:
	 Content-Transfer-Encoding;
	b=Wy8ROvt1N4Z0L/+sVpRbP6Kw9zPPWFy70mdtYBjd48snQhmbV6g+4atAE83epDHNY
	 rDw2m+sjY2yQScbkdHlvRLfpgI42uiHe2s1tDCzktKLMhOkKfoKVUuokYxy6E38
X-QQ-STYLE: 1

又看了一下国外的邮件。这封是Apple的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Received: by 10.52.240.19 with SMTP id vw19csp6991vdc;
        Thu, 19 Dec 2013 09:53:37 -0800 (PST)
X-Received: by 10.182.199.70 with SMTP id ji6mr2349588obc.36.1387475616772;
        Thu, 19 Dec 2013 09:53:36 -0800 (PST)
Return-Path: <[email protected]>
Received: from msbadger0406.apple.com (msbadger0406.apple.com. [17.254.6.147])
        by mx.google.com with ESMTP id kv3si3864744obb.149.2013.12.19.09.53.36
        for --;
        Thu, 19 Dec 2013 09:53:36 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 17.254.6.147 as permitted sender) client-ip=17.254.6.147;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 17.254.6.147 as permitted sender) [email protected];
       dkim=pass [email protected];
       dmarc=pass (p=REJECT dis=NONE) header.from=insideapple.apple.com
DKIM-Signature: v=1; a=rsa-sha1; d=insideapple.apple.com; s=insideapple2048; c=relaxed/simple;
	q=dns/txt; [email protected]; t=1387475613;
	h=From:Subject:Date:To:MIME-Version:Content-Type;
	bh=Bv+phsUVfuOBtsYL10tJhisQ4Wo=;
	b=ZH+peisWOL02/c8ekXM3LGk1LQeRGXQecRnvRreYqL+neIvqQw/dZL8kzTxUC/mf
	NMLqzVTil0qwoqnxSDzxNX4vRdqszeQsJRXZh2dvZQhJZ6hDeHc0Jh0AaWPQPN3Z
	M1tRvtGkdek2VzH8sU7pAPT6lB+4SEFtHvBIFUi+aQ/yoqHGEfsSs9qwgK3iAHtl
	1Sc+5GcTdebDUExWoA/qpc4JOGSi9qbBZUN5zsqncRHiiSHtW8qc+onJYR1EpGuQ
	S4mOKFIozNP3r7YYt9GCP6gXKkcRnrAqeWUTExSx041B1lDY+hzNLCcvq881Jp8H
	LaMhQIxfwT+OS6O4wopSIA==;

SPF， DKIM非常详细，并且最重要的是 DKIM签名的域就是发送域。所以有这样一句：

1
Received: from msbadger0406.apple.com (msbadger0406.apple.com. [17.254.6.147])

这样的邮件是安心可以点击的邮件。各种unknown域的邮件，大部分是可以造假的。

后来我又从其他邮箱中找到了各种来自豆瓣，知乎，三巨头 阿里，百度，QQ的邮件。所有的邮件中要么没有DKIM,要么DKIM的域和发送的域不一致。导致都是unknown的IP地址。这样的邮件大部分可以伪造，想想如果CSDN/支付宝/百度/腾讯，让你提交个身份证 Or 地址电话什么的。大概也会有人连想都不想直接点开链接，下载其中的附件。所以，国内的email环境实在是不安全。以后，看到CSDN发送过来的邮件，还是三思而后打开吧…

Posted on Edited on Word count in article: 920 Reading time ≈ 1 mins.

昨天，server调用新浪的OpenAPI功能失效。出现的现象是：服务器上线时是可以正常使用的。但是隔一段时间就变得不可用。刚开始以为是socket连接过多或者socket等资源没有释放。后来查了一下socket连接发现不是这样子的. 下面是连接新浪服务器的tcp。发现只有两个。

1
2
3
4
5
6
7
$ netstat -np | grep 123.125.29

tcp        0      0 -- ::ffff:123.125.29.244:443   ESTABLISHED -                   
tcp        0      0 -- ::ffff:123.125.29.244:443   ESTABLISHED -                   
$ netstat -np | grep 180.149.135
tcp       28      0 -- ::ffff:180.149.135.176:443  CLOSE_WAIT  -                   
tcp       28      0 -- ::ffff:180.149.135.176:443  CLOSE_WAIT  -

后来还看了HttpClient的源码和PoolingClientConnectionManager, 发现并不是这个引起的。另外给大家说个事情。使用Http Client+PoolingClientConnectionManager，然后再使用HttpGet和HttpPost的话，HttpGet和HttpPost是不需要release的.另外socket也不需要显示的关掉。唯一需要注意的是HttpResponse需要把Entity中的Stream流关掉。否则请求有可能被Hold住。详细的介绍见 HttpClient 卡死 response为null . 如果你不是使用HttpClient+PoolingClientConnectionManager， 而是每次new出来的新HttpClient,那就需要关闭Socket，详细解决方法见 JAVA的HttpClient问题：The server failed to respond with a valid HTTP response 。但是上面都没有解决问题， 最后还是将HTTP的status code打印出来。发现是：

1
HTTP/1.1 413 FULL head

这问题出在，有多个线程在往HTTP 请求中增加Header， 而且header一直没有清空。就导致了这个问题。

0%