原来不止我发烧就做同样的梦啊.我的梦是这样的: 在一个没有边际的空间中,一个不规则的立方体不断的变换着,但是整个感觉是非常压抑被死死的束缚着, 如果突然松开后,也就醒了,就是一身汗,基本就退烧了

@jimmyczm 视经销商良心而定 !!!, Intel NUC 出厂只有主体. 硬盘,内存,电源是经销商自己搭配的.(可以咨询 Intel 售后) 所以,这三个部分给你配的好就还可以,质量差就各种问题. 我们因项目需求陆陆续续采购了快 50 台了,目前出问题的已经有 7 台左右了....... 拆开后你会发现各种品牌的内存和硬盘都有

觉得力不从心应该是指 对目标任务的拆解力不从心,无从下手的感觉.而是某个语言学不会. 我相信让你做个视频转码的小工具,把一个视频转码成另外一种格式.是能做到的. 但是让你写一个应用软件.这就是涉及到软件工程了.
界面布局
人机交互
文件系统
存储,通信等等最后还要整合到一起. 需要系统的学习,也需要经验...

1. 一个 CPU 核心,在一个具体的时间点,注意是时间点,比如 某 xxx 纳秒的时候,是仅仅有一个线程是运行状态,而其它 9 个都不是. 建议复习一下 线程的生命周期. 另外,线程是你代码执行的容器,并不是你代码本身. 当你代码在某个线程中执行完后,线程就销毁了. 而线程池则是让你代码执行完后,线程并不销毁,而是重复使用. 再就是线程安全主要指的是内存中变量的读写在同一时刻只有一个线程可以操作.
2. 并发数超过线程数后,请求确实是排队中的. 只不过每个请求的处理时间很短,基本毫秒级别就结束了. 打个比方,某个请求处理耗时 5ms,那 1 个线程 1 秒就可以处理 200 个请求.理论上 10 个线程就是 2000 个请求,但线程切换是也是要消耗时间的.所以实际上达不到 2000,也正是因为线程切换要消耗资源和时间所以线程数不是越大越好.

尽管总结的字数很多,但看起来没有触及到根本问题. 需求调研没有做细致,缺少架构设计能力.任务拆分不合理.

需求调研不细致,才导致各种 "万万没想到"; 才会让你低估项目难度, 进而导致任务分配给了不合适的人身上.

缺少架构设计能力,4 个项目,老框架,中间件,插件,设备,按理说应该先收集评估相关技术,然后设计整合的架构方案.然而并没看到,而是直接分配任务了. 也会导致任务分配给不合适的人.

制造业工厂一个工厂也就一个 IT 部门,维护一下网络,电脑等,即便是程序员基本也是写点小脚本,主要还是与外包沟通需求,跟进项目进度为主.

但有一类公司,非标自动化公司,无论大小,基本都会有那么几个软件开发,目前先进一点的用软件+板卡的形式控制设备,low 一点的与 PLC 交互做采集,做所谓的数字孪生或者智能工厂

我来说一下 1/1000 DDD
1. 问题领域识别: 明确你面对问题所在领域. 例如 你要完成一个用户登录功能. 那么 往大了说,这属于 "信息安全领域"
2. 领域建模: 将这个领域中的处理模型搞清楚,并映射为对应的计算机语言设计,例如面向对象设计,将这个领域中的对象设计出来.

所以,起始最核心的是 "领域专家 " 这个角色,他有充分的专业知识和经验 能够给最初设计给出完整的领域知识的指导. 而程序员通常是计算机的"领域专家",并不是信息安全领域的,也不是 财务方面的,也不是仓库,物流,运营方面的. 如果领导让程序员去 DDD 本身就不是靠谱的事.

再退一步,其实实际工作中,"领域专家" 90% 情况下不存在.大家几乎都是自己岗位的熟练工而已....如果不信可以找公司会计问问,如果要开发一个 财务系统,希望他给你讲讲财务领域的知识,同时让他给设计建议,保证你最后实现了,也就你们公司能用. 根本达不到 财务领域 通用的程度.

一堆人费劲心思提出了这么个 Promise 规范,解决异步带来的麻烦, 然后你要在这基础上硬生生的在退回原始方式....

@zhigang1992 你他娘真是个人才

个人看法,单纯讨论语言没意义. 要看你发展的领域. 如果还是 Web 方向,毫无疑问是 Java.
如果但是如果是工业自动化领域,毫无疑问是 C# . 各家设备厂商提供的 SDK 基本优先 C#版或者 Dll

首先,你可以这么写程序,java 并没有限制你不能这么干.
不过,你要明白 new Object() 等于开辟了一块内存区域,而方法调用的时候,方法中的上下文(this) 可以等同于 这块内存(不严谨). 举例:
``
public class MyObject{

private String name ;

public MyObject(String n){
this.name=n;
}

public void getName(){
return this.name;
}
}
MyObject obj_1 = new MyObject("张三"); // 开辟了 内存 A
MyObject obj_2 = new MyObject("李四"); // 开辟了 内存 B

obj_1.getName(); // 张三
obj_2.getName(); // 李四
``
那么,如果全部是 static 方法,可以自行查阅一下 static 方法内存怎么管理的. 然后上述功能如何体现.自己写一下可能就能理解这么干的优点了.

你可以看看 JeecgBoot ... 功能更强一点.
另外你可以将生成代码的路径直接指向源码目录,然后配合 JRebel 这种热更新的工具就能达到你期望的目标.

当然生成的代码的目录结构与源码目录结构可能不同,这时候你可以自己搞个目录监控,将生成的源码自动拷贝到源码对应的目录下即可.

普通的写写逻辑你可以不关心原型链，无非就是声明个变量，if-else ，for 循环。
但是，如果你是处在核心研发团队，做框架，并且还提供个其他人用，如果你不懂原型链，那肯定不敢用你，鬼知道你把 “this” 给了谁。

如你所说：“其实时间都是消耗在网络 IO 上” 线程是不解决 IO 问题的，你需要的是 异步 IO 处理机制。一个线程同时处理多个 IO ，而不是一个线程处理一个 IO 。

代码 "臃肿" 并不是问题. 个人看法是 耦合度太高.无法应对需求变动,建议参考其它用户,权限,角色管理系统. 我个人认为存在的问题有这么几个
1. login 方法中的参数,未做比较严格的校验,如果客户端传入了 10 万字符长度的,你这里会不会卡?
2. 是否可以将参数校验单独提取为一个 方法? validator
3. 用户黑白名单与角色的功能是写死的,如果需求变动,是需要改代码的. 如果允许可以使用 apache shiro 这种成熟的权限框架,如果觉得重,也务必将 授权,鉴权 独立为两个模块,方便扩展.

重要的事情 吼三遍
协程的目的不是提升性能! (当然比纯线程还是有提升的)
协程的目的不是提升性能!
协程的目的不是提升性能!

协程是简化了多线程开发难度!
协程是简化了多线程开发难度!
协程是简化了多线程开发难度!


可以用 多线程版完成一个 3 个生产者,2 个消费者程序,再用 Go 的协程+channel 实现一版,就更能体会到了, 更像是一种语法糖. 其意义在于从语法层面降低: 多线程 /异步 开发门槛.

C#吧，Winform ，拖拽个界面。使用 HTTP 协议与 Java 通信交换数据，例如 Flurl ；
然后 Java 端内置一个 Jetty 作为 web 服务；

缺点： 仅适用于 Windows ，无法跨平台；界面稍微不注意会很丑
优点： 快，Java 端逻辑可以完全复用。

换个梯子的节点就好了,可能是某些节点的问题.

@pkoukk 或许你根本不理解什么是 "计算机语言" 手动狗头
1. 你认为的生态如何重要了?

2. 那 Go 语言的设计逻辑与 Java 差别在哪里了?

3. 各有适应场景又如何解释?

请赐教