好喜欢红茶啊！！！
可惜喝多了会进入狂暴状态！

代码不好维护不是因为 OO 或过程式代码的原因。这两种代码不管哪种，写的好都很好维护。

然后看具体情况来选择哪种方式写代码。

而要让项目好维护，需要在很多地方下功夫。命名、文件组织、方法体大小、模块依赖关系、注释、文档、逻辑表述、选择的库的易用性等等，各种细节都做好了，项目代码才好维护。维护问题不是说用 OO 就能解决的，更多的还是看人和管理模式。

@chanmian95600 还没赚钱的游戏公司，运维通常都很轻松。赚钱了，那服务器铺开来的量，运维有的辛苦的。

楼主根本没说清楚这个网络压力测试是用长连接还是短连接。是走 tcp 协议还是其他协议。到底要测什么的压力。

就我所知，常见的语言都可以用来写网络压力测试工具。就我的经验，大多数情况下，网络压力测试工具尚未发挥最大性能时，对面的被测试服务通常是先挂掉了。

LZ 应该先用自己最熟悉的语言写个压力测试工具，等遇到瓶颈了在考虑具体问题具体分析。

另外，写任何东西，都不要把性能问题考虑的很重！程序性能对于一个项目来说，通常都是很小的一个因素。后面的开发迭代可以有各种方法把性能提上去。太早考虑性能只会让自己裹足不前。

LZ 如果来我们公司，不用面试，我直接招你入职！

@shiji 想请教下一般是什么样的 BUG 。
@ColinWei 我们公司内组装了个工作站，跑 VMWARE ESXI 的虚拟机用。用的超微的板子， 2 颗 ES 版的 E5-2650 v3 的 CPU ， 128G 带 ECC 的 DDR4 内存。价格是 1 万出头点。用了半年，还没重启过。
如果是公司内网使用，对稳定性要求不是很高，并且预算有限，可以考虑淘宝上组个。
长期来说，优化软件和数据库为主。你找 DBA 优化，如果没效果，至少要让 DBA 说明什么原因导致负载太高了。

楼主需要找个女朋友。最好是要求楼主有房有车才能结婚的那种。

先考虑自己想干什么，在考虑学什么。有目标了才好努力。
比你想做网站，那学 js 什么的。
你想写 App ，那维持现状或学个 Swift 什么的。
你想当黑客，那学的就多了去了。
反正在其他领域是一片白纸，那么哪个方向都可以，尝试了才知道自己要什么。

@ncisoft 我的意思是绝大部分需求是不需要那么高的实时性，更多时候是需要更大的吞吐量。所以 Oracle 的 JDK 对于大部分人来说已经够用了。

@ncisoft 大部分情况下 Oracle 的 JDK 已经可以满足需求了。 6G 内存以下用 CMS 回收， 6G 内存以上并且 CPU 强劲用 G1 回收。
最重要的是不要出现内存泄漏，另外是在确保代码可读性的基础上减少不必要的对象的创建。

我们负载最终的服务的 Xmx 是 30G 内存， 24 核的 CPU 。由于是 tcp 长连接的，并且要求是毫秒级的响应，是不允许出现 full Gc 的。

感觉楼上的答案都没有说到点子上。现在 Java 不管是 CMS 还是 G1 ，停顿延迟都已经很低了。如果遇到 stop-the-world 的停顿，甚至达到了几分钟。那么绝对是因为内存泄漏导致可用内存不足，从而触发 full Gc 。
这种情况一个是看看 Xmx 是否设小了，另外就是好好查查代码中是否有内存泄漏。
开发环境下做个压力测试。然后 Java 内带的 jvisualvm 可以看基本的内存增长。如果内存慢慢涨到 Xmx 的极限值，那么就是有内存泄漏。如果真有内存泄漏，仔细检查代码，另外到网上下载个 jprofiler ，然后耐心的开始找哪里泄漏了。

@xuboying 这类公司很多。
如果作为开发者必须要用外网，就不要去这样的公司。如果作为老板或主管，希望保护自己的知识产权，就放开手做各种物理隔绝，不用在乎别人的意见。
这类事讨论对错没有意义。

你们说的已炸是指什么？貌似还能访问哇。

为什么好多人对国人做这类改造的事情没啥好感呢，我感觉只要遵守许可证，不添加有害的东西，这类事情就是好事。

@mengzhuo 感谢回复
这个语言内置的官方库目前来说感觉比 Java 好用。很多东西写起来也比 Java 简洁，这个是我觉得还不错的地方。

关于 1 ， vendor 我们已经在用了，这点解决了多个项目不会依赖同一个版本的第三方库的问题。
而这里其实是想说的是，一些第三方库没有语义化版本没有 tag 的问题，比如 redigo ， github 上是看不到语义化版本这样的信息的， godep 导入进来后，记录的是非常长的 git 的 rev 信息。可能有人会说，作者能确保每次合并到 master 上的一定是稳定的版本。但没有语义化版本，有时候很难向别人解释为什么我当前要用这个版本。如果库之间有依赖关系，也很难看懂他们的依赖关系， A 库如果依赖 B 库，那么依赖的是 B 库哪个版本对外的接口？所以库缺少语义化版本，可能会对未来项目的长期维护造成麻烦，我们不敢随便升级库了，因为不知道是否有 API 的不兼容。

关于 2 ，没有私有仓库，只是觉得不方便，到不是什么大的问题。 godep 和 maven 在使用上还算接近。希望有组织能早日实现个私有仓库。之前写 nodejs 的东西，在中国这个大环境下，考虑是否将 node_modules 中的文件提交到版本库简直是噩梦。提交到项目版本库的话，项目要多几万个文件。不提交，根本没法获取依赖。

关于 3 ，是我自己说的有点问题，其实是想说没有抽象类的机制，一个接口有很多实现的时候导致要写许多重复的代码。 interface 的话，的确用起来比 Java 灵活很多。所以两者比较，感觉也没啥，多写点就多写点吧。

关于 4 ，我写过几年 C++，写过几年 Java 。 golang 的这种不加星号就不是指针的变量声明方式间接的引入了变量不可变性，不过在函数式编程没有普及开来的情况下，变量不可变的意义就不是太大了。所以就会发现周围的人为了实现功能以及为了以后维护省心点，写着写着，所有的方法或函数的参数都变成了传指针了。很少有人会认真考虑从我这个接口传进去的结构不能是指针，因为数据在内部是不可变的，并且产生多份数据对内部更深的代码是没有影响的。如果大家声明的所有变量几乎都是指针的话，个人感觉语法反着来可能更舒服一点，即一切皆引用（指针），当需求明确了或需要优化或结构数据不能在方法内部被修改时，再考虑将方法参数明确修改为值传递。目前很多其他语言也是这么实现的吧。
当然，现在 golang 有这种现成的变量不可变机制的话，也希望 golang 能更早的实现出可用性很强的函数式编程的范式来。

其实正如楼上各位提的， golang 语言本身 ok ，习惯了问题不大，目前感觉阵痛主要还是因为配套没跟上。

@dbdd 很多时候生活中没有那么简单的选择题让你做。

经济学里面有个词叫做机会成本，你得到的东西的成本是你所失去的东西。
然后理性的人在边际处思考，你多工作几个小时的收益是否抵得上你的损失。

所以要判断多工作几个小时的好还就是看，你多工作这么几个小时后，你自己的能力的提升、得到的报酬、上司对你的评价等等这些收益是否抵得上你失去的自由生活的时间、你的健康损耗、你的朋友关系等等这些损失。

如果项目能锻炼人、上司依能力提拔下属、加班的报酬或者项目成功后的提成不错，而自己又是单身，年轻身体还可以。那么短期的加班未尝是损失。
相反的话，那么就要考虑是否还要加班下去了。

所以最基本的一个原则就是加班要为自己而加，从自身出发来考虑收益和损失。