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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 761 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

CPU

上下文

线程数

服务器

17 条回复 • 2022-11-28 23:49:57 +08:00

lingalonely

2022-11-27 13:27:31 +08:00

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

Jlzeng

2022-11-27 13:34:41 +08:00

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

nmap

2022-11-27 13:51:05 +08:00

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

kidlj

2022-11-27 13:58:47 +08:00

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

opengps

2022-11-27 13:59:18 +08:00

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

xuanbg

2022-11-27 16:40:03 +08:00

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

clf

2022-11-27 17:59:18 +08:00

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

2.签保密协议就行。

berg223

2022-11-27 19:52:52 +08:00

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

wangritian

2022-11-27 20:12:45 +08:00

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

akira

2022-11-27 20:23:04 +08:00

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

dqzcwxb

2022-11-27 20:54:49 +08:00

把线程池换成 forkjoin

vitoliu

2022-11-27 23:12:44 +08:00

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

vitoliu

2022-11-27 23:15:15 +08:00

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