Java多线程：等待线程结束后打印END的自定义解法为何不被认可

解法1（新增join但保留sleep）不通过的原因 #

• Thread.sleep()是静态方法，你通过s1.sleep(1000)、s2.sleep(1000)的写法本身就不符合编码规范，实际生效的是让运行这段代码的主线程休眠，和s1、s2两个子线程没有任何关系。
• 保留sleep会带来无意义的性能损耗：无论子线程是否执行完成，主线程都会先空等1秒，哪怕两个子线程10ms就执行结束，也要多等990ms才会执行后续的join逻辑，完全不符合高效编码的要求。
• 逻辑冗余：join本身已经可以实现等待子线程执行结束的能力，前面加的sleep没有任何实际作用，考察线程基础的测试场景自然会判定这种写法不合格。

解法2（循环检测isAlive）不通过的原因 #

• 存在语法错误：Java中线程的存活状态查询方法是isAlive()，你写的IsAlive()首字母大写不符合方法命名规范，且s2.IsAlive漏写了括号，代码实际无法编译通过，你自测能运行大概率是拼写错误是提问时的手误，但哪怕修正了拼写，这种写法依旧不合格。
• 属于忙等待实现：空的while循环会持续占用CPU资源反复判断线程状态，会造成不必要的性能浪费，相比join基于操作系统线程调度的等待实现，完全是错误的工程实现思路。
• 同样保留了无意义的sleep代码，和解法1一样存在性能损耗的问题。

官方解法的优势 #

• 没有冗余的sleep逻辑，子线程执行完成后会立刻执行后续的打印逻辑，没有额外等待耗时。
• join()是Java提供的原生等待线程结束的实现，底层基于wait/notify机制实现，不会占用多余CPU资源，是符合规范的标准实现。
• 代码简洁无冗余，逻辑清晰。

内容的提问来源于stack exchange，提问作者Vrbovszki Bence