请教两个线上问题该怎么做好

[plko345]

第一个是一个 java 服务接口被打满，出现无法接收新请求（ hang 住），开发检查后发现线程数上升到 1000 多，认为这是 cpu 不足导致（ 4 核），需要加服务器，但 cpu 利用率和上下文切换都比较低，不过加服务器确实能提高这个服务的总体并发。我认为临时加是没问题的，先解决紧急情况，但他们得把这个接口优化下，提高单实例并发数，不过他们不同意这点。

第二个是安全相关的，怎么防止代码源码传到外面，各位公司有什么机制想参考一下

[lingalonely]

1. 第一个问题，我可以理解为一个请求处理时间过长，导致后面请求堵塞么，看你描述应该是这样的，这种大概率通过异步的方式可以解决。
2. 第二个，我知道的情况是基本做不到，除非类似华为的管理方式，单纯技术角度是无解的，还不如花大精力在账号安全上，防止相关账号流出

[Jlzeng]

1 、加硬件能解决问题，就最好别动代码；
2 、通用做法是云上开发，代码只能在远程云上解密和编译，但一切手段都抵不过社会攻击，只能在招聘时防范；

[nmap]

第二个是应该考虑的问题吗？商业公司的代码有个鸟价值，有价值的是数据！

[kidlj]

1. 假设一个请求一个线程来处理，线程积累到 1000 多，说明线程处理请求慢。这时候可以加日志，看一下是哪一步导致的响应慢，大部分情况下问题出在 IO ，比如读写数据库。这样就可以有针对性地优化请求响应时间，线程数也就会回落。

[opengps]

第一个问题，短期还是要用加服务器数量即可解决的“通用办法”，提高单机承载力属于后续的慢工
第二个问题，根本不需要过于在意，非超高的科技行业里，代码本身并无价值

[xuanbg]

第二个问题真的没必要过多考虑。我们从来就不缺代码，也不缺拉屎的程序员，缺的永远是肯吃屎的程序员。。。至于不拉屎的程序员，咱就不奢求了。

[clf]

1.加服务器，后续找个架构师看看。

2.签保密协议就行。

[berg223]

1. 从你的描述来看，应该还没搞清楚瓶颈在哪，瓶颈可能是磁盘，网络，内存，肯定不是 cpu 。我认为在没有找到问题根本原因之前提出的方案就是扯淡，包括无脑加机器这个方案。我不理解你的友军为什么会不同意你提高实例并发这个建议，我认为他们不够专业。

[wangritian]

cpu 占用低但请求进不来，可能是程序内线程池或锁控制住，也可能是依赖的服务跑满（这时候加机器也解决不了），带宽跑满也容易被忽略

[akira]

对于问题 1 ， 服务器成本 和 人力成本 做下衡量就是了。目前你们现在还处于早期业务验证阶段，这个时候业务才是最重要的，优化只有在成本失衡的时候才需要去考虑

[dqzcwxb]

把线程池换成 forkjoin

[vitoliu]

第一个问题，cpu 利用率和上下文切换较低，但是接口还是被 hang 住，从我的经验来看，考虑下是否因为线程并发任务太多导致内存不够频繁 GC ，
如果是的话只需要扩大 jvm 内存就行。
如果不是的话，先临时加服务，后面可以 dump 下堆，看看具体是哪些线程一直在占用 cpu ，代码里面是否有特殊处理。最后判断下当前接口的性质，如果是强业务接口（各种跨服务和事务调用），4 核机器的确可能处理有限，如果不是的话肯定就是代码问题了。

[vitoliu]

第二个问题，要想防止代码流传到外面很简单，做好员工监控，公司配电脑，安装流氓软件，出口网关流量分析……
不过最终效果不一定好，只能说目前大厂基本都是这个操作。

[zbatman]

第二条，建议在每个员工工位后装摄像头，再买一套深信服的监控系统，设置定时全屏截图员工屏幕上传。如果还不放心，再给每个程序员招个“程序员监控师”，坐在程序员边上，人盯人

[WhatMelon]

第二个问题要不看看 数篷科技

[plko345]

谢谢大家, 第一个问题主要是不知道如何跟他们沟通, 说服他们去找到根本问题并优化

[plko345]

@vitoliu
@zbatman
我也是员工, 还是不坑自己和同事们了, 这些方案听起来好残忍🤣