能干啥活，不管它迷你不迷你。一分钱一分活，2500 预算就只能是个上网本。1000 一下的低功耗迷你主机，NAS 、旁路由场景，这个相对比较成熟。1000-5000 档位的迷你主机，本质上就是小机箱台式机，不是不管用，但基本不会有宣传的好。5000 以上，体积就控制不住了。

一个月等得了的下家，不一定不是坑。一个月都等不了的下家，铁定是坑。

小红点专利快过期了吧，猜一下到时候苹果跟风「其他厂商对小红点的跟风」的概率有多大

IaaS ，是从一片垃圾服务器集群中，虚拟化出来一群随时迁移的虚拟机，不是先找好宿主机再在宿主机上给你搞虚拟化。这跑你妹的分。

这大概是「几十年」前的销售推广，因为很早就把技术人员开了只剩商务人员，就一直这么往外面忽悠人。代码安全审查领域，你只要见得多了，就总会碰到这样的坑爹玩意，客户资质越高，越容易碰到。

greasyfork 上架，请遵循 greasyfork 的规则，跟开源有个屁关系。

看了楼主后面的回复，我上面的回复应该是白瞎了。

追本溯源，Java 的线程池，其设计目的不是为了线程池，它是异步执行器的无奈实现。Java 内置的线程池，你只能把它当作异步执行器来看。而异步执行器，它只保证新任务能被快速接受——以不阻塞任务的提交者，不保证新任务被立刻执行——这很可能导致后续任务提交被阻塞。如果你要的是类似连接池那样的同步调用场景的池子，你得自己设计非异步执行器的线程池。

另外，即时是常规线程池，你也没办法保证任务被立即执行，因为线程启动不等于线程里面的任务开始执行。

"先判断是否达到最大线程数在判断任务队列是否满了"为什么不可以？

为什么要可以？你定义的 n < m ，那不就是打算让它再非繁忙情况下只运行 n 个线程吗？你现在又让它在刚 n+1 个任务就开新线程，这在现实中就是瞎指挥的「领导」。

@OutOfMemery #3 好像是很久之前用过的，先记录一下，后面再慢慢研究。

@a33291 虚拟桌面跟多屏（虚拟显示器），这隔离的不是环境，而是 Windows 任务栏+任务视图。不完美——桌面文件、开始菜单这都是公用的，有限制——应用程序本身要支持多窗口，但你的场景下差不多能用了。

多用户同时远程的前提是，多用户「多会话」操作系统，你要么 Windows Server ，要么 Linux ，要么虚拟化，Windows 普通版还不虚拟化，就不要想了。你这还是涉及到网络的跳板机，那虚拟化也基本可以排除了。

对阿里网盘抱有不切实幻想的人，可能是只经历过百度没经历过迅雷，只撞一次头不信邪。现在你百度跟阿里都撞了，要是再出个网盘还有幻想，那就是脑子有病了。

「（比如表单的名字，输入规则，校验等等）」，「具体到业务逻辑我们自己再去完善」：如果前后这两大阶段都是人做的，那么整个编码就只剩非常小的一点工作了，还需要什么 GPT ；如果这俩你人不做，那么人都看不懂的东西，GPT 也做不了。

当然，跟低代码、代码自动生成工具一样，不是完全没用，是能抽走大量低级重复工作的。不过，只要是上了年龄的开发，基本都会明白：虽然我们总是在蔑视复制粘贴，但是「复制—粘贴—调整」往往比「提取公共—维护公共」，或者「提取公共—不维护—废弃已过时公共—重新提取」更有效。