为什么做 Java 开发的公司需要那么多程序员？
Java在工程化方面做的更好，不论项目管理、开源生态、人才供给上等都占据了极大的优势。您看到的：做java开发的公司需要那么多程序员只是个结果。什么意思呢？通常来说，对于人的需求并不是语言的特性所致，而是业务发展所致。不论用什么语言，只有在公司快速发展的时候才会对人有大量的需求。
那为什么被大量需要的都是Java呢？因为之前说的那几点，管理上够成熟、生态上够优越、市场上可以招聘的候选人更多，由于这些因素的存在，导致了公司在技术选型上对于Java的偏向，脱离上面的优势，选择其他语言，是很有可能在公司发展道路中成为瓶颈的，比如：当你想扩大产品线，由于用了小众语言，这种招人会非常困难，如何支持你产品的快速迭代呢？同时，看看那些目前已经做大的企业，他的初期可能并不是Java，但是随着业务发展，也做了技术转型的例子已经不再少数，最终他们都走向了哪里？没错，就是Java阵营！
所以，楼主看到的只是个结果，那些开始就用Java的不断发展，会需要更多Java程序员；那些开始不用Java的不断发展，也有可能会转型到Java，所以，Java程序员的需求量是巨大的。
我就问你，公司业务扩张需要从5人扩容到50，你用c/c++ 能在2-3个月的时间招到这么多人吗，放低标准招到了，你能有效管理好吗，能控制得住产品质量吗
java真能，或者说java做到这点相对容易点儿，这就是Java本质上的竞争力
能做到这点是因为java在工程化和抽象上做得很不错（语言与框架基础水准就很高，做架构的人不需要多么强的能力），招来的人做业务即可
本来没想太认真回答这个问题，但是经过不断补充完善，现在已经超一万两千字了。有些描述不当的地方，还有拼音输入引起的错字，都请及时指正。有些文字可能比较偏激和悲观，但我的本意是希望能够唤醒那些做企业应用的公司和里面的Java程序员。
作为一个41岁的老码农，确实需要给刚入行的新人或者正在项目组迷茫的程序员交代点什么了。
本文的主要内容：
领导层的梦想，以及九大特点。
程序员的梦想，以及三大谎言。
三个不愿分离，三个不愿统一。
正是上面这些原因造成公司觉得程序员永远不够用。
科学技术是第一生产力，人不是！如果非要说人也是，那么只有掌握科学技术的人才是。
科学技术是第一生产力，管理不是！如果非要说管理也是，那么只有适应当前技术并能解放生产力的管理制度才是。
如果想学习Spring Boot和Typescript/Angular/React，可以加我微信:32698325。
最近搜我号的人太多，评论区有人反映搜索异常了。也可以先关注我的公众号：全栈通途
--------------------下面是回答--------------
透过现象看本质。
Java是企业应用市场的王者，如果一家非互联网公司用Java，那么十有八九是做企业应用的。
所以，这个问题本质上是：为什么做企业应用的公司需要那么多Java程序员。
开发企业应用的公司和程序员都有其自身的特点，我们分别展开说一下。
我们先说说做企业应用的公司
下面9点不一定在所有公司身上都存在，但肯定是大同小异。
- 相对于互联网来说，企业应用不是一个公平竞争的市场。互联网公司创业之初往往是因为有好想法好技术，企业应用公司创业之初是因为老板有人脉有关系。大部分做企业应用的公司都是靠老板的人脉关系活着，靠在某个领域的关系垄断霸占着这块业务。而且也因为老板和高层习惯于人脉和关系，公司也会形成官僚国企文化，而不是工程师文化。所以这些公司技术老旧薄弱，技术人员也从来不会被重视。很多公司虽然有个高新技术认证，但根本没有任何技术含量可言。
- 客户是甲方是老板的上帝，老板得罪不起，因为得罪了就自毁人脉和关系，就没有在这个行业立足之本。特别是行业圈子有限，客户之间都是有联系的，得罪一个就会传到别人拿去。所以甲方可以蛮横的在需求、设计、技术方案等各种环节上提出自己的修改要求。而绝大多数甲方都是自以为是，什么都不懂，仅仅是为了表明自己懂或向领导证明自己懂。在项目实施过程中，和客户对接的程序员完全处于弱势。心中几万匹草泥马奔腾着，却要点头称是，敢怒不敢言。
- 有些甲方其实根本就不懂自己的行业，或者根本不能代表最终用户，不知道自己的需求到底是什么。往往就是一句话：你先做出来再说。所以无意义的需求变更过于频繁，甚至有可能彻底推翻重来。而且这些甲方都是恨不能XP用一辈子的人，他们见不得任何新颖的设计。比如你用了现代化的前端，他们反而不买账，就觉得老界面舒服。你用Spring Boot了，他们认为你连Tomcat都不知道，反而觉得你太Low。这就更进一步助长了公司内部一些不思进取的人，他们拿着尚方宝剑说：用户不认可这样！
- 项目招标同质化竞争，明着互相压价、暗着陪标围标等各手段都上。一家公司提出免费维护三年，另一家就可能提出免费维护五年。反正不管将来怎么样，先要把这个项目拿下来再说。最后项目工期可能是合同上的两倍，而且还要面临着验收后好几年的维护期。维护期往往就需要搭一个人进去，没有任何利润可言。最后造成项目整体式亏本，能收支平衡就不错了。
- 不像互联网应用那样，客户是网民，没有地域限制。企业应用的客户很可能不在公司本地。客户需要人员驻场开发才放心，我花了钱了就要见到你们的人，否则我怎么控制进度，我怎么知道你们是不是用最后两个月突击完成的。所以差旅住宿成本飙升。为了能有新项目收入，就必然不惜血本继续拿新项目。然后新项目又不断压价，造成恶性循环。
- 公司成立之初，可能有几个骨干技术人员。随着公司慢慢发展，他们就成了技术副总、技术总监、技术经理什么的技术管理层。但是这些人基本不会自我提升，而是想着如何继续把公司的技术把控在自己手里，让自己永远坐在过去的功劳簿上。所以他们就禁止技术升级，禁止他们不会的任何技术出现。这样他们才有用，他们才能管理新入职的程序员。
- 公司不重视技术，也就不重视技术人员。技术人员永远是三等公民，远没有销售的地位高，也不如财务、行政等职能部门那些会拍马屁的。程序员在项目的投标、实施的整个生命周期中没有话语权。投标时，销售为了中标就胡乱承诺功能和时间进度，根本不会和实际开发的技术人员商量。往往只是给技术总监打个招呼，而技术总监不会考虑底层程序员的利益。实施中，面对客户的需求变更，销售和技术管理层不会和用户讨论需求变更的原因和合理性，而是会配合用户软硬兼施让程序员去实现。
- 在企业应用的公司里，除了程序员以外，所有人对软件开发的理解就是堆代码搬砖头，人月神话在他们这里一次一次真实上演。一堆砖头，4个人6个月能搬完，6个人4个月也可以，上12个人就可以用2个月完成！所以从老板到销售到技术总监，一遇到进度问题首先想到加人。不管是需求的原因还是技术上的困难，能给你加人就是对你最大的恩赐。
- 为了降低人力成本，也为了让客户看到自己公司人多，所以就招聘低水平的研发。本来应该招聘一个两万四的，但更愿意招聘两个一万二的，最后招聘的是三个八千的。这些人谈不上架构水平、代码质量、自测什么的，造成项目交付质量极差，往往让客户充当了测试的角色。这就进一步让客户对公司产生怀疑，认为公司没有全力投入，就要求你驻场开发。
总之，所有的这些因素都在不断恶性循环。循环的结果就是：做企业应用的公司可能会发展变大，但是不会变强。变大是因为研发和后期维护人员摊大饼式扩展。不会变强是因为技术常年不会有任何变化，人员层次常年不会有任何提升。没有人从提升技术水平和开发效率的方向去考虑问题，都在想如何拿更多的项目、如何跟客户玩游戏。
多说两句：
我毕业19年，一半时间在开发企业应用的公司。经历过几百上千人的国企，也经历过十几个人的小私营公司。面对的行业有政府、电网、电信、民航等等。09年以前是Weblogic平台国内专家，后来主要是Spring+前端。现在还在给多家企业做技术咨询顾问，帮助他们整体技术提升。这19年，我从未见上面的恶性循环趋缓，而是还在不断恶化下去。
每一个有点理想的做企业应用的公司或老板都有一个梦，就是产品化。说白了就是能把产品刻成光盘卖(当然这是传统的做法，现在方网上下载也行)。因为只有这样才能突围出怪圈，走上由大变强之路。这需要公司有非常深厚的行业经验，了解用户的想法，抓住用户的痛点，从中总结和归纳出通用需求。需要有非常强的架构和设计能力，让产品可以按需裁剪、灵活定制。需要有非常强大的编码和测试水平，让产品能够稳定顺畅。
为了能够实现产品化，但又要面对现有技术水平太差的现状，很多公司就采用项目养产品的策略。就是专门成立一个产品部门或团队，从其他项目组抽调技术人员，或者新招聘几个所谓的高手，集中力量研发产品。
产品研发是一个周期长、成本高、风险大的工作，而且在真正出来满意产品前是不挣钱的，只能靠项目赚的钱来输血。这种策略往往都是失败的，因为没有一个公司有实力、有耐心去长时间养着一个不挣钱的团队。所以，几乎没有公司能实现这个梦想，都会重新回到摊大饼的老路上。
这几年一线城市生活、租房等成本飙升，而且必然会传导到程序员的薪资要求上。原来社保福利能不上的不上，必须上的按最低标准上。以后社保由税务部门统一征缴(现在暂缓实施)，那就逃不掉了。所以，最近几年会有大批做企业应用的公司裁员或完蛋。因为研发人力成本是公司经营成本中最大的一部分，这部分成本在加速上升。原来活的好的公司会面临巨大压力，原来活不好的公司会面临死亡。
本回答中的一些观点可以参考我之前的几个回答。
企业软件开发考古断代学：
现在(2018-10-12)还有必要学SSH框架吗?三体智子理论：
为什么国内 IT 公司 leader 以上就不怎么写代码，而据说 Google 的 Jeff Dean 还写代码？到底哪种情况好呢？上面说的是公司，下面咱们说说技术和技术人员
面对企业的负责人，我经常描述一个场景：有一个工地，几百号人在用铁锹铲子挖坑。我找上门去，问工头：你们知道有一种设备叫挖掘机吗？有的不知道，有的知道。有的以前在别的工地见过或开过，只是来这边以后没机会用了。如果我开一辆挖掘机来，用一天时间干的活就相当于你们这一个工人一个月的工作量，你相信吗？而更重要的是这个挖掘机是免费开源的，不用花钱买，仅仅需要学习掌握如何操作。
这几百号人的工地就是企业应用项目实施团队。而我说的挖掘机就是Spring Boot + 前端(Angular/React/Vue)，当然也就是我现在推广的JHipster。
正像我上面场景里描述的那样，有很多技术负责人和普通Java程序员都知道Spring Boot和前端框架。但是对于他们来说有点遥远了，可望不可即。有的Java程序员自己在偷偷学，跃跃欲试，但是这种技术氛围的公司不可能给你实践的机会。有的技术负责人也认识到了新技术能够为公司技术带来的提升，但是苦于自己也不会，更没有能力对下属培训和指导。如果新招聘会的人，自己连面试问什么问题都不清楚，又怕招聘来个水货。总之这些所谓的“新技术”对企业应用市场造成了一定的冲击，但企业自身却有各种困难无法把新技术转换成真正的生产力。
我会给一家企业介绍讲解现在主流技术栈，并且给他们的员工培训。还会让他们自己找一个典型的业务模块让我用新技术去重新实现，然后把新技术实现和他们以前老技术实现作对比讲解。这些过程完成以后，他们都会认同铁锹铲子和挖掘机之间的差距。这时他们就会在内心深处面对另一个难题：破梦。
什么是破梦？就是打破程序员的梦，把他们从舒适区赶出来。
之前说过，每一个有理想的企业软件公司都有一个梦，就是产品化。而公司里的Java程序员也有一个梦，就是手头会的东西能用一辈子。自己永远待在思想的舒适区里，不想动脑子，不想转换思想，只想日复一日做重复的工作。有一句话是叫：没有公主命却有公主病，这里应该是：不是铁饭碗的命，却做着铁饭碗的梦。
这个梦比公司的梦更容易实现，不用花一分钱，不用开一次会议。有适当的土壤和水分，种子就会发芽，而做企业应用的公司就满足这些条件。可怕的是，这个梦是集体的梦，而不是一个人的梦。如果只是一个人的梦，这个人会被淘汰。如果成为集体的梦就会开始逆淘汰，那些不断提高自己不断学习接受新技术的人会被“淘汰”。
在我见过的多家公司，这个梦已经实现了。
加班？不愿意啊... 但可以接受！
出差？不愿意啊... 但可以接受！
薪资没有互联网公司高？不愿意啊... 但可以接受！
学习现在的主流技术栈，提升开发效率？不愿意啊... 不但不能接受，还有很多理直气壮的理(谎)由(言)拒绝你！
下面三个谎言比较常见：
1，这个技术不适合企业应用！
说这句话的人，大部分认为某项技术只适用于互联网。他们简单的认为互联网和企业应用在开发上有很多不同，而很多技术天生就被打上了不同的标签。但实际情况不是。
没有专为互联网应用开发的Spring Boot，也没有专为企业应用开发的SSM/SSH。没有专为互联网应用开发的React，也没有专为企业应用开发的Angular。
没有一家互联网公司只有为普通用户开发的界面。滴滴不可能只有给乘客和司机用的两个App。阿里巴巴集团，上到马云下到普通员工，不可能成天顶着天猫和淘宝界面浏览。他们都有自己的中后台系统。蚂蚁金服的内部，也不是天天只访问支付宝界面。
就蚂蚁金服的中后台系统复杂的就不亚于一个国有商业银行，腾通的中后台系统绝对不会比电信的简单。
最近在给多家企业推广Ant Design。当然们看到Ant Design文档中这段话时，深表认同：
蚂蚁的企业级产品是一个庞大且复杂的体系。这类产品不仅量级巨大且功能复杂，而且变动和并发频繁，常常需要设计与开发能够快速的做出响应。
从 2015 年 4 月起，Ant Design 在蚂蚁金服中后台产品线迅速推广，对接多条业务线，覆盖系统 800 个以上。
有做企业应用的公司有800个系统吗？蚂蚁金服的中后台产品线有，而且还仅仅是已经推广了Ant Design的。
2，这个技术不成熟！
事实是他根本没有去深入了解这个技术。往往当他说完这话之后就不会再和你继续讨论了，他说这句话的同时就算是给你最盖棺定论了。
不成熟的技术，当然不在公司乱用，万一影响到项目进度和质量，谁能付得起责任？
不愿意花时间去深入了解一项技术，不勇于“试错”，有怎么知道这项技术不成熟呢？
就像我在这个回答中说的一样：
2018年已过一半，为什么绝大部分前端团队还是无法重视Angular？不了解的就是不成熟的，不成熟的就是不能用的，不去用就永远不了解。这个死循环永远打破不了。
3，这个东西太难用！
有些技术，因为他们听的太多了，耳朵都磨起茧子了。或者是别人强迫他们去学习了解的。当他们遇到一点点困难就甩出这句话，然后就没有然后了。
在我的多个回答里，反复强调一句话：软件开发首先是思想活动，其次才是敲打吗。
到底存在不存在不适合学编程的人？思想最难的就是转变。一个新技术或新框架，往往是因为旧技术或框架无法支撑其新的思想才出现的。或者说，新技术就是代表了新思想。技术的进步就是思想的进步。
可是有些人学习一个新东西，就是要往自己已经会的东西上套。套不上就是难用！可是完全套上了又和之前的东西有什么差别呢？
我们在参加工作前，做了十几年“学生”，难道不就是学习“生”疏的东西吗？学习就是转变思想的过程。学习一个新技术新框架，就是跟着作者的思想在想问题。想明白想通了，处处顺风顺水。想不通，觉得别扭，开发也束手束脚。
回到前面我们说的铁锹铲子和挖掘机的话题上来。当企业负责人意识到挖掘机对自己生产力会有变革性的提升时，他们就会在内心深处面对这样一个难题：公司内程序员的梦怎么破？那些理直气壮的谎言怎么才能揭穿？
下面回复评论区的一些观点
回复评论区 @井田 和 @契蛾 ：
莫名其妙的回答。企业软件要的是业务，根本不是开发技术，国内用友、金蝶等公司用java开发的erp只能在外围当做数据字典使用，真正下到生产实际中连20多年前的pb开发的程序都替代不了。
企业应用场景 技术从来不是重点。
这是企业软件行业常见的谎言和借口之一。企业应用就是面向某个特定行业开发定制化的软件，所以关注业务很重要，这个没错。但并不是说根本不是开发技术，或者技术从来不是重点。
我本文说要用新(其实一点也不新，而是主流，只是对于某些公司来说永远新)技术，目的不是替代20年前的程序，而是提高企业自身的开发效率，并且降低成本。
我们就不说新技术能够给开发带来多少便利，能够让原来无法实现或很难实现的需求变得多么容易，能够让用户体验度提升多少。这些都属于你给一个没见过电的人描述电能如何改变生活一样，他始终认为蜡烛和煤油灯能满足自己的需要。我们下面单从很多公司能否活下来这个角度看看技术的重要性。
一家企业软件公司，技术人员占比多大？一个有三五年经验的Java程序员薪资是多少？五到十年所谓老Java开发薪资是多少？本公司的行政、财务、市场等职能部门的人干到退休可能都拿不到他们现在的薪资。所以，在一家企业软件公司，技术人员的薪资是人力成本的大头，绝对的大头。因为他们人数占多，平均薪资又高。
如果我通过技术升级能让一家企业软件公司的研发人员数量减少一半，同时效率提升一倍，你觉得企业老板乐意吗？当然乐意，而且是梦寐以求的。一个薪资是一万五的程序员，社保和各种福利算上，企业实际承担两万。开源节流，省下来的钱也是钱。这还不算由于人员减少一半带来的水电、租用办公面积减少等的费用节约。
事实上可以做到通过技术升级，让企业软件公司的研发数量减少一半，同时效率提升一倍吗？通过我这几年的经历证明是可以的，而且这个目标还是保守的。
所谓的技术升级，不仅仅是从现在企业软件公司万年不变的JDK6 + SSH/SSM + JQuery/LayUI + MyEclipse升级到Java 8 + Spring Boot + Angular + IDEA。而是整个软件开发流程、思路的改变，是整个软件开发观念的改变。
就好像我上文描述的场景。并不是从铁锹铲子换成挖掘机就完事了，而是由于挖掘机等现代化作业设备的出现，改变了施工的工序和管理制度。对于开发企业软件的公司来说，开发思想和理念的升级，比纯粹升级换代技术要更难！
在做企业应用的公司，经常有人“语重心长”的说业务才是最重要的。仅仅是因为他们感觉自己略微比别人多一点行业经验而已，我跟你比不了技术，我在这家公司多待了几年，比你接触业务多，我就和你比这些。每个公司确实都需要行业专家、领域专家，但是这些懂业务的专家应该和技术分开。他们只需要用自己的经验和用户沟通，然后用文档清晰明确的描述需求，而实际情况是项目经理要求既懂业务又要带头干活。业务和研发的分开，才能保证业务更精通与业务而不被技术所累。才能保证技术人员的正常流动，避免去别的行业又不熟悉业务，只能受困于一个行业。
经常有人在知乎上抱怨“面试造火箭、入职拧螺丝”。我不相信那些能懂Java底层虚拟机、多线程，能搞清楚Spring的IoC、依赖注入、分层结构，能搞清楚各种算法的程序员搞不明白那些业务。仅仅是他们不想把时间和精力用在业务上，他们觉得自己不会长时间在这个行业干，技术才是能带走的东西，业务会扔在老旧的项目里一起埋葬。他们会买一本Java的书看，会买一本前端的书看，会买一本算法的书看，会上知乎提技术问题，哪怕会上CSDN翻翻博客也好，他们绝不会花时间主动去研究业务！
回复评论区 @lzclong：
企业应用里面技术要为业务服务，就像你自己说的技术的升级换代能节省企业成本改变企业文化，但是确实很难苟同你所谓的“技术才是能带走的，业务会随着老旧的项目一起埋葬”。试问不懂核心业务，你怎么判断所谓的多线程设计是不是合适？片面的割裂技术与业务的思路都是不可取的。
同意你的让业务和技术更专业。
但是在一家专注做企业应用的公司里面，80%的团队成员不能仅仅把自己定位于技术人员，技术人员不吃透业务应用场景，基本上都会陷入老虎吃天无从下口或者不负责任制造无用、低效率代码的地步。 纯技术人员从来都是那20%（或者更低比例）的金字塔尖的一波人。
昨天晚上花了好长时间回复你，可是睡觉了才发现内容没有保存上。现在重写。
我没有否定业务的重要性，我也同意要有吃透业务的人。我的观点是分离，不是分割。分离是让业务专注于业务，让技术专注于技术。
业务人员甚至可以不是计算机专业的，甚至可以不会编程。他们可能是行业内对口专业的，也可能是在行业内深耕多年积累丰富经验的，也可能是行业内退休的专家被聘来做业务分析和指导。
在项目初期，主要是业务人员在分析和分解业务，最终的成果就是设计文档。设计文档能够让技术人员纯粹用技术的视角就理解任务就知道该如何去实现功能。当然肯定不会这么完美，这就需要业务和技术的交流。
就像前后端分离一样。服务器端不用JSP了，并不是说没人负责界面和用户交互了，而是由更专业的前端框架完成这部分功，然后前后端分工配合实现整个应用。
我刚毕业的时候，2001-2003年做过两年对日外包。那时候还没用上Struts，就是纯JDK1.3 + JBuilder + JSP/Servlet。每周一，日本人和我们用Yahoo! Messenger 视频会议，把这周要开发的任务讲解一下。如果有我们不懂的业务，他们会给我们解释。我们要在周五下班前把本周开发并自测过的代码发给日本人。日本人利用周末的时间测试我们的代码。下一个周一会先把周末他们测试的结果给我们，然后继续讲这周的开发任务和业务讲解。我们先把测试的Bug改了，然后开发本周的功能。就这样循环滚动下去。
我没有从日本人那里学到什么Java编程技术，但是却在这种工作模式上深受启发。两组语言不通的人，隔着那么远的距离，仅仅靠翻译就能协同工作的如此顺畅。日本人把软件开发任务分解的非常合理，每一小部分的需求描述的非常清晰形象。就像流水线上的工人一样，他甚至无需知道最终生产出来的产品是什么样子，只需完成好自己这一道工序的操作就好。这就是任务分解，而任务分解的前提是设计清晰，能够细化，能够形象描述。
对日外包前，我已经考取了SCJP(Sun Certified Java Programmer)。对日外包做完以后，我认为架构和设计能力很重要，所以自己又学习并考取了SCEA(Sun Certified Enterprise Architect)认证。在SCEA的学习过程中，我发现UML不就是业务和技术之间的桥梁吗？UML就是让不懂编码的人能够通过图形的方式分析业务，然后清晰明确的描述业务。
UML里面的图形分成两类吧(Structural UML diagrams和Behavioral UML diagrams)。其中Behavioral UML diagrams里面的Activity diagram、Sequence diagram、Use case diagram、State diagram等等，不就是让不懂开发的人分析、描述、确定业务的吗？Structural UML diagrams里的Class diagram、Package diagram、Object diagram等等才是懂面向对象概念的程序员用的啊。
后来我开始接触Weblogic Platform，对Server、Portal、Integration都熟悉了，后来进一步熟悉了Weblogic Aqualogic。发现BPMN图形语言更丰富，更适合描述复杂业务流程！
之前我举了一个流水线的例子。我再举一个例子。某建工集团的工人。这个建工集团总包了一个普通居民楼的工程，这些工人去了能建造出一栋栋居民楼来。下次这个建工集团可能会总包一个鸟巢水立方的工程，还是这些工人去了能把鸟巢水立方建出来。再下次，如果他们去建造大裤衩，还是能完成任务。这其中的关键在于设计能力，以及设计的层层细化能力，是一个产业成熟的标志。绝对不会要求每名工人既懂居民楼的业务，还要懂最现代化的体育场的业务。当然，你也会经常见到有设计师对着图纸在施工现场。当然，鸟巢水立方引入了很多最新施工工艺，需要对工人做一些特殊说明。这就是我之前说的业务和技术之间需要配合和交流。
UML图和专门用来分析复杂业务流程的BPMN都是行业标准了，但是却被我们搁置在一边。让每名工人都既懂得设计和建造大裤衩有能设计和建造普通居民楼。要么你的职业生涯就老老实实困在我这里建造居民楼，去别的地方你不懂业务。这写都是产业不成熟的表现。
说到分离，再多说几句。
做企业应用的公司害怕分离，总以为都掺在一起才是最直接最省事的，分离就是自己给自己找麻烦，就是脱了裤子放屁。但事实是相反的。
我现在能想起三个层面的分离，很多数公司都不能同时做好。能实现一个层面的分离已经是难为他们了。
1，前后端分离。老生常谈了，我自己都烦了。不多说，多看看我其他相关回答。
2，人员分离。上面讲的就是，但不仅仅局限于此。还应该包括前端人员、服务器端人员、测试人员等等的分离。往往在一家公司，业务、(如果分前后端的话)开发、测试都是一同组人。
3，环境分离。严格区分开发(dev)、测试(test)、演示模拟(staging)、产品(prod)环境。最低要求是分为开发、产品两个环境。
充分利用Spring的指导思想和提供的特性，分成application-dev.properties(yml)和application-prod.properties(yml)两个配置文件。
比如我就禁止研发人员在自己的电脑(尤其是笔记本)上装数据库。因为这台机器是开发环境，有H2这类专门用在开发环境的数据库呢。见过太多程序员把Oracle、SQLServer装在自己的笔记本上，然后成天喊太卡，要求公司加内存。
最后的所谓发布和部署，就是把笔记本上的代码复制一份到客户服务器的Tomcat下。简单、省事、一步到位，这就是我们企业应用开发最聪明之所在。
现在的前端开发也要用webpack配置开发和产品，开发环境方便调试、热加载、测试，产品环境会优化、混淆、压缩。从开发到产品要npm build一下，这让企业开发的人觉得不可思议。干嘛要这么复杂？不就写个JS吗？
做企业应用的公司也不愿意统一，总认为统一就是束手束脚，统一就是约束了自由意志，限制了个性的发挥。事实同样是相反的。
我现在能想起三个层面的统一，也没有企业能够都做好。
1，统一开发环境配置
我曾经写过一篇文章，介绍Chocolatey：
陈龙：Windows统一开发环境的基础-Chocolatey公司应该给出一个明确的开发软件配置列表，包含用到的所有软件，以及他们的最低版本和基本配置。其实现在的Java服务器端开发机器只需要JDK和IDE就可以了，不需要安装Tomcat、Maven、数据库。可以参考我这篇文章：
陈龙：不装Maven、Database、Tomcat 才是Spring Boot的正常开发模式见过太多人把JDK或IDE装到类似 G:学习资料Java开发工具 这种路径下面。见过无数次“为什么在我这能跑，在你哪里就不能跑了”的怪现象。由于路径含有中文或空格引起的错误，由于安装路径和版本不同造成运行差异的问题，都屡见不鲜。
在这些统一的基础上，其他可以自己定制。例如你喜欢暗色编辑界面，他喜欢亮色编辑界面。因为这些不会影响到开发。
2，统一代码风格
这个就不说了吧，大家都知道，但是没有公司能做到位的。找一套编码风格规范很容易，但是让每个人都养成习惯太难，定期有人做代码复查就更难了。
3，统一组件库
公司内用什么第三方库，最好有统一的要求，需要升级的时候统一升级。
前端用jQuery、Underscore/Lodash，要求统一到什么版本。用了Select2/Chosen，需要用某一个版本。等等不再例举。当然如果用现代化的前端开发，比较容易用package和package-lock统一版本。服务器端最好有自己的Maven库，用Nexus很容易就能搭建。
上面讲的害怕分离和不愿统一，总结起来的根源就是：习惯原始小作坊化、逆工程化。机械、建筑、纺织、电子、哪怕是某些国家的农业都早已进入了现代工业化大生产阶段。但是软件开发，特别是企业软件开发还将长期停留在小作坊阶段。
什么是工业化大生产？
工业化就是专业分离。一家大飞机的几万个零件，又全球不同国家不同企业研发制造。一个零件，要经过若干道复杂的工序才能出厂。你们不是号称自己精通业务吗？你们看看自己熟悉的行业是如何分工的。不分工明细，何来如此复杂的业务流程。
工业化就是标准统一。只有标准集装箱，才能促进全球贸易往来。只有统一的铁轨才能让火车跑起来。只有统一的电压和频率才能让大家放心购买电器。你们不是号称自己精通业务吗？你们看看自己熟悉的行业都有多少标准！我经历过国家电网、电信、民航等行业，标准繁多啊。
回复评论区 @还是无聊的人：
做企业应用的人到现在的习惯思维还是JSP，不让用JSP了就想到Thymeleaf，反正思维总是局限在服务器端。而我们必须要认识到，以前前后端分离是一种选项，今后前后端分离则是必须。更多观点看我的这个回答：
Java新手如何学习Spring、Struts、Hibernate三大框架？Java Web 开发使用 jsp 页面是否已经落后了？是的话现在流行用什么？因为企业应用脱离不了Spring，不管现在是SSH还是SSM都在Spring的体系内，下一步升级也必然不会脱离Spring生态，而Spring Boot是必然的选择。Spring Boot是Spring现在最重要的项目，也是Java服务器端近些年唯一跟上时代的亮点。更多观点看我的这个回答：
spring boot和SSM开发中有什么区别？哪些企业或项目在用Spring boot,或者它会在多大程度上替代Spring?Spring Cloud也是构建与Spring Boot之上的，所以Spring Boot是今后架构迁移到微服务的必由之路。更多内容看我这个回答：
Spring boot与Spring cloud 是什么关系？Spring Boot本身对JSP就有一定的限制，当架构迁移到Spring Cloud的时候，JSP就彻底无用了。因为所有的前端都必须发送AJAX请求给Spring Cloud的API Gateway。
所以，以前用SSM/SSH，JSP是主流，前后端分离是可选。用Spring Boot，前后端分离应该是首选。用Spring Cloud，前后端分离是必须！
回复评论区 @moshanglalaxy :
刚开始读前面我一直以为我就是这种陈旧的人，后来你说挖掘机是springboot？.....我居然这么先进了吗
如果Spring Boot是挖掘机的话，那仅仅是挖掘机。现代施工作业不仅仅靠挖掘机，还有很多工程机械合使用，搅拌机、打桩机等等。
所以前提是Spring Boot这个的挖掘机要使用正确。不能开着挖掘机心里想着铁锹的操作要领。就像我上面回复评论区中说的，用Spring Boot还在想JSP或其他模板语言，否则就不会用了。
其次，Spring Boot要和前端框架配合好，利用好REST API，做到前后端分离的开发。而且为将来有可能的微服务迁移做好准备。
Spring Boot解决了服务器端各种框架的集成配置问题，而JHIpster包含Spring Boot，并给你了前后端最佳搭配的样板。
回复评论区 @黄浩：
做企业应用的公司永远谈不上技术，所有的技术都是在迫不得已的情况下被动的接受。为什么Struts2换成SSM？还不是因为现在用Struts的人太少了，不好招人了。培训班都已经不教了Struts了，而是以SSM为主了。喜欢技术、乐于创新的人在这样的公司永远不会发挥自己的优势。项目经理其实就是比别人多几年经验更懂一点业务，然后顶着个“经理”的头衔带头干活的。
所以，认清了环境后就要分析自己，你适合做技术还是适合混体制。喜欢论资排辈、温水煮青蛙、技术十年如一日，那就好好混。否则，趁年轻多学技术，找机会换环境。
我的一些相关文章和回答
想学习Spring Boot和前端开发的同学，看我的文章：
陈龙：从0开始,5分钟创建一个Spring Boot + Angular/React应用陈龙：Java EE开发的颠覆者？Spring Boot 十问陈龙：跟我一起学Spring Boot + Angular/React全栈开发感谢这个问题并没有人邀请我。
我是自己来答的。
从几个方面来阐述这个问题：
1.为什么一家公司里面C/C++(以下简称C)工程师的数量远远少于Java。
大部分情况下，C所负责的功能有以下特点：
- 逻辑相对简单
- 黑魔法代码多
- 难以多人维护
所以，数量少。
2.为什么是Java？
虽然我已经很多年没有写过Java了，但是在我的印象里面，Java在项目管理和多人合作方面，成熟度应该是最高的了。它擅长于大量的人协同完成一项复杂的开发工作。
3.扩展来说（会跳出本问题），有些公司在做表面上与别的公司相同的业务时，使用了更多的开发人力，那么他们应该在做（可能包括但不限于）以下的一些事情：
把『可用』做成『高可用』
- 在安全上下功夫
- 在自动化上下功夫
- 在产品化上下功夫
- 在标准上下功夫
等等
其实你这个问题本末导致了，不是为什么做java的公司需要那么多程序员，而是为什么需要那么多程序员的公司选java
当业务变复杂，事情超多，团队配合的场景变多，不管用什么语言，都需要很多程序员。这时候沟通成本会急剧提高，见过白天开会晚上写代码的工程师吗，跟你说，我就是。
同时我们希望每个人把自己那块东西做深，做精，也不希望一个人干太多领域，但是每方向都是皮毛，这样对公司，对个人也都不好。
所以你会发现人变多了，每个人写的代码却急剧降低，大厂一个开发专家写的代码都不如一个创业公司普通员工1/10多。但是他们解决的问题可复杂的多，上下游依赖，涉及若干团队协作。
所以人多是必然。
然后，技术原型你会发现，那个如此灵活和运行效率低的Python在这个场景下根本不好用。其他极客语言go市场上也没啥高手，项目需要上线产品运营都要急得跳墙。
而java，社区框架成熟，市场人才储备丰富，语言经过多年演化，虽然不入Python灵活，但是也不容易出错，即使新手写也不会太惨不忍睹。那么就索性用java吧
一种情况是传统企业的弊病，不愿转型，不愿尝试新技术，这无关于语言，都一样。
另外一种情况，人多真的只能说明业务多而已。
由于其强大的生态，java在微服务时代，项目的复杂性和开发周期可以说是数量级的降低的，开发人数是和业务的量挂钩得更加紧密，剩下的就是老生常谈的开发效率和可维护性的权衡而已。
今天我们换个方式，不写文字了，用一通表情包来回答这个问题。
JAVA的第一个问题是内存消耗。有一半JAVA工程师没在写业务功能，他们在解决内存问题。而另外一半，在制造内存问题。
JAVA第二个问题是OOP，在理想状态下，OOP编程下的企业级应用会变得非常可扩展，足以应对快速变化的业务。可惜的是，OOP的设计需要同时精通业务知识和编程技巧，这样的人，一个公司100个程序员当中能有三个都算是多的了。
最后，最大的问题在于团队。程序员这种生物，是人越多，效率越低的。最好的紧密团队应该不超过7人，但是企业级的业务太多，小核心需要的时间不足，于是就增加人数，人数的增加，带了几何级数的复杂度，导致需要的人更多。。。。恶性循环直到换系统。
那汇编要的人更少，几乎看不见招聘，是因为它最高级最便捷吗？
软件开发中，一个人干一个人的活，五个人干4个人的活，100个人，干50个人的活，这是正常现象，那你说我招50个人干50的活不行吗？
答案是50个人，就是只能出30人的活，项目越大，需要的人越多，而相应内部消耗也就越大。
所以cpp要的人比java少，可能只能反应出一个问题，那就是如今用cpp写大型项目的公司已经很少了。
因为这些公司如果改用C或者C++, 将需要更多的程序员。
目前在硅谷， 只有Google和Facebook这两家互联网公司敢用C++作为主流后端语言，但这C++语言本身的library和工具有限，尤其在多线程和内存管理方面对程序员的素质和能力有更高的要求， 所以要招更优秀的程序员, 而且公司要自己开发丰富的library框架和工具。
聊个真事，17年的项目，对于老板来说是大项目，实际也就一百多万，甲方是一家不差钱的体制内单位，要求驻场开发。作为前东家小头目，我二话不说，带了十个兄弟奔赴前线。
进了庙门，拜了菩萨，甲方经理微笑着问：“贵公司怎么就派这点人来？我负责的上一个项目，人家可是一开始就派了30几个人过来呢。”
要知道，咱这十个人里面，有四个都是现招的，30个人是要修路盖楼还是怎样？我只能尴尬而不失礼貌回应：“还有一半的开发在远程支援，主要这边住宿不方便……”
对方表示理解。直到现在这项目还没验收，可以说是非常合理了。
大多数甲乙双方的思维还是人海战术，Java只是赶上了企业级开发的破车而已。然而思维方式不变，换成Go、Python也不会有区别，这和十三亿人的国家足球稀烂是一个道理。
我来说说我们公司的，我们公司安卓2人，ios1人，其他的都是java,然后我们java又分成三个小组，我们小组和我和另外三人负责H5（H5又分成三个项目，安卓和ios同）和接口编写，然后我和另外两个同事还要负责另外一个项目的数据采集和解析，话说来公司都5个月了，还没用过spring。数据采集和解析全都只能用原生的java来写，今天老大说还要我和另一个同事再去帮忙做管理中心，说实话工作以来第一次感觉老板真的好黑，期待966.icu协议早日加入开源协议，话不多说github支持一波吧。
后端从数据采集到接口编写至少涉及到三个项目，而数据采集有涉及到多数据源。所以大部分工作都是在后端做，而前端的工作主要就是展示。
互联网公司：靠招一两个大牛缩减人数来降低成本
企业级软件公司：靠招一堆搬砖工降薪加班降低成本
互联网公司：我这系统撑千万级的量会炸
企业级软件公司：我们多少量都不会炸，反正一万以上我们就拒绝服务
互联网公司：我们要保证功能简单精确，做好用户体验，保证用户留存
企业级软件公司：真正用这系统人根本没有话语权，做的好不好用根本没关系，把所有能堆的功能都往上堆，好让给钱的人觉得自己的钱没白花
互联网公司：我们靠给用户发红包赚投资人的钱
企业级软件公司：我们靠给采购发回扣赚政府企业的钱
互联网公司：不说了，我带 ppt 去忽悠投资人去了
企业级软件公司：不说了，我带两瓶茅台跟领导喝酒去了
贡献两个案例
10年前杭州某银行系统外包给北京一家公司，那家公司当时派了40多人去。实际上这里面只有5-6个人是主力干活。剩下那些人坐那里啥事都不干，经理不在还可以玩玩3C。甲方很满意：因为人很多。
13年我在HK HP。隔壁有个组连PM八个人。主力是个家在广州的大陆人。有次他老婆生小孩，于是他就拿了产假回去一礼拜。结果那一礼拜进度停了，也不OT了。最后 连甲方都發现了：为什麽某人一走，你们就乜都冇嘅？
后来查看工作进度，此人和另外一个兼职的大陆人承担了80%的开发工作。
这两家公司主力开发语言都是java。
所以你说为什麽要这么多人呢？
java是一个可以一个人写个main方法，
再把main方法做成一个工程，
再把这个工程做成一个项目，
然后拿这个项目找一堆人开发然后去忽悠投资人的语言。
不记得在哪里看到的，很经典。
比如开源offbiz，里面每一个小组件，小功能，国内公司都能拿去做一个金融级的项目拿去赚钱。
需要人多有一个原因我知道，甲方要求驻场人员，或是要求本次项目必须有多少人，反正甲方出人头费。有这种好事，还不多招点？
因为程序员死的快，需要源源不断的补给
我也回答过类似的问题，因为java是对企业友好的语言。
为什么这么说？首先java是强类型的编译型需要，很多问题在开发，测试的过程中已经发现了，减少在生产环境出现也最的可能。当然java也有运行时，也有数据带来的bug，这些就靠其它的机制。
其次，java有强大的生态来保证代码质量，代码规范扫描，单元测试，持续集成。目的也是为了提高效率，同时降低出现问题的风险。
再次，java强调的是设计模式（开发套路），其实框架有了的话，你就往里面添砖加瓦就可以了。这样就是在前人经验的基础上做，目的也是提高效率，降低风险。
那么java对企业友好，对开发者呢？其实并不十分友好。它的冗长死板一直被诟病，python几句实现的功能可能java要写半天。那怎么办，请更多搬砖的来做吧，所以就有了如今这样的现实。
没有语言黑，python和java我同样喜欢。。。
1.Java程序员门槛高
首先要计算机技术或是相关专业的大学生，原因有二，一是，Java对从业人员素质有一点要求，计算机相关行业会了解最基本的互联网的相关知识，以及简单的语言基础；二是，从事这一行业，招聘公司对学历有要求，最起码要是专科以上的。
当然，也不排除有非计算机专业的从事Java行业的人，但是万事开头难，很多人抱着很大的希望去学习，随着遇到的困难越来越多，慢慢的也就放弃了，因此有一部分人都倒在了入门的路上。所以干这一行的人相对其他行业还是少。
2. Java行业市场需求存在巨大的缺口
这几年中国在移动互联网这块发展非常迅猛，各种创业公司、小团队如雨后春笋般冒出来，对Java开发的需要变大。但存在人才发展跟不上市场的需求的现状，相对应的给优秀Java人才开出的薪资待遇随之水涨船高。
3. 程序员的确很辛苦，需要不断学习、进步
辛苦分劳力和脑力两种，劳力工作不难，每天重复着体力活；但脑力活就不一样了，程序员一辈子都在学习、在挑战，因为这是一个不进步就out的行业。
随着互联网的发展，很多企业随着业务发展要求服务器程序更稳定，更可靠。如：京东，淘宝等大型人网站均采用Java框架进行开发。银行券商等机构均采用Java作为开发语言。
对于在职的Java从业人员来讲，不断的努力吸收新的知识，跟上互联网进步的节奏是很重要的。
Java的应用可以说是无处不在，从桌面办公应用到网络数据库等应用，从PC到嵌入式移动平台，从Java小应用程序(Applet)到架构庞大的J2EE企业级解决方案，处处都有Java的身影，就连美国大型太空项目当中，也使用了Java来开发控制系统和相关软件。用途如此之广的Java造就了Java工程师的辉煌，使其在软件工程师的领域里独占鳌头!Java软件工程师运用Java这个开发工具去完成软件产品的软件程序设计、开发、测试、维护升级等工作。
随着Internet的迅速发展，Web应用日益广泛，Java语言也得到了迅速发展。1994年，Gosling用Java开发了一个实时性较高、可靠、安全、有交互功能的新型Web浏览器，它不依赖于任何硬件平台和软件平台。这种浏览器名称为HotJava，并于1995年同Java语言一起，正式在业界对外发表，引起了巨大的轰动，Java的地位随之而得到肯定。此后的发展非常迅速。
Java编程语言的句法与C++的句法相似，语义则与Small Talk TM的语义相似。Java编程语言可被用来创建任何常规编程语言所能创建的应用程序。
链接：Java编程开发人员的工资为什么那么高
来源：百度知道
作者：荒唐年华谁记下
推荐阅读：
- 2019年java的学习路线是怎样的？
- 哪儿能找到从头到尾全过程解说的 Java 学习视频？
- Java培训机构可靠吗？
- 为什么大多公司不要培训班培训出来的JAVA程序员？
- Java的前景如何，好不好自学？
- 新手该如何一步步的学习 Java？
- 关于 Java 学习，有哪些值得推荐的书籍或教程？
- Java 初学者，如何学习 Java
感谢邀请。根据五月份的语言排行榜来说，java仍据第一位。
终端研发部：5 月编程语言排行榜：Java第一，R跌出Top20而在2019年3月数据库流行度排行: Oracle 依然坚挺，MySQL大幅增长成月度赢家 ，java之所以能排第一的，
在语法上，java和C/C++没什么区别。论性能，在复杂应用的表现上，java也没有明显的弱。java代码能跨平台通用。相当于是一个解决了平台无关性的C语言。
无论是开发环境的组建，还是后续产品部署，都具有了直接用C所不具备的灵活性。所以在应用开发上，倾向用java会是不错的选择。
在生态上，java比python之类的要好太多：功能丰富，运行稳定。随着工具链的完善，java的开发代价也比python之类的高不了太多。所以很多应用的开发，选java会比python更方便。
这样比较一下，发现java确实会长期是编程语言的第一名。
虽然Java应用最广泛，但与其它语言比并没有什么技术上的优势。常会看到各种抱怨，说Java语言设计不如C#，对native的精确控制和灵活性不然C++，动态性、开发效率方便不如Ruby，Python，Node，在高并发领域又不如Erlang，中间应用层又远不如Go、Swift等，但为什么它一直是编程语言排行榜首，并且在大公司中广泛应用呢？
比较同意一种说法，Java最大的优势不是它的跨平台性而是它庞大而完善的生态系统。它的流行最主要原因还是由其生态系统决定的。
- Java语法不复杂，入门简单。语言各方面比较均衡，拥有最值得信赖的GC，避免很多码农的低级错误。并且天生的面向对象设计，更容易模块化开发。再加上Java强类型静态语言，只要框架已搭好，即便开发人员能力不足，也基本能保证代码质量，这在大项目的协作开发、维护方面很有优势。
- 开源，拥有大量的第三方库，并且大部分质量有保证，可以拿来就用，对软件生产效率的提升所带来的巨大价值。正如一句话所说：“我们不生产代码，我们只是Github的搬运工。”并且Java拥有很多杀手级应用，如Spring，Apache、Android，Hadoop，Spark等。
- 拥有免费好用的IDE——Eclipse，通过插件几乎可以满足日常开发的任何需求。
JAVA语言的本质优势
转载自：https://blog.csdn.net/bingshanyijiao_fkx/article/details/51613954
角度一：
优点：简单、安全、稳定、跨平台 缺点：需要运行环境、不适合开发桌面应用程序 应用：BS结构的ERP系统、金融系统、电子商务系统、网站等 几乎所有的银行系统和银行网站都是基于Java平台的，你可以访问看看。
角度二：
优势：
（1）一次编写，到处运行。
（2）系统的多平台支持。
（3）强大的可伸缩性。
（4）多样化和功能强大的开发工具支持。
角度三：
1、跨平台性，虽然是很好的优势，可以让JAVA在任何的系统中运行，但是前提是该系统要安装JAVA虚拟机，这样导致一些JAVA编写的桌面程序无法在一般的用户（没有安装JAVA虚拟机的用户）上使用
2、JAVA的身后是SUN公司，提供及时的API更新，但是过多的版本导致JAVA的向下兼容性很差。而SUN公司在J2EE上的标准定义的并不是完美，导致在J2EE的开发中多数使用开源框架，开源框架是好东西，但是更新速度并不快。
3、都说面向对象的语言先进与面向过程，JAVA是OOP语言，但是它适合的是BS系统，在WEB项目中JAVA的实力毋庸置疑，但是转到了底层的程序却无法同C++抗衡。
4、个人认为JAVA的最大优点是开源，但是这往往也成了最大的缺陷了，无法定义一个好的标准使得开发时使用了框架，在新的程序员来到公司时必须先了解框架，延缓了开发的时间。 世上必物极必反，JAVA是个好东西，未来的程序将越来越完美，如乱码是JAVA的第一公敌，但是我相信几年后定会解决该问题。
不管怎么样，最重要的是，Java在不断的进化，并且在慢慢的进化，正如罗胖在刚刚过去的《时间的朋友》跨年演讲中说的那样“我们喜欢进步，更喜欢慢慢的进步”。
JDK1.4性能很大提升，基本被人接受
JDK1.5增加泛型、线程池、注解
JDK1.6进一步提升性能
JDK1.7加了Try with Resource，switch String等小功能，多线程方面也有改进，性能再次提升。
JDK1.8加入lambda, stream等功能，功能上有了很大的升级。
最后，Java拥有世界上数量最多的程序员，更容易招到人。
关注个人公众号【终端研发部】
搜索不到的，可以通过这个图片地址：
https://upload-images.jianshu.io/upload_images/14371339-f32babf99c596cc6?imageMogr2/auto-orient/strip%7CimageView2/2/w/800/format/webp
- 回复【Java】可以得到java全套学习资料和视频详解
- 回复【面试题】可以领取各种非常实用的大厂面试题
- 回复【Spring Boot】可以领取springboot相关的学习资料和详解
- 回复【职业规划】即可免费获得8技术大牛的职业规划课程，职业不再迷茫。
社会需求大,现在许多企业软件/服务器后端都是用java开发.
虽然解决方案成熟,许多软件架构都是类似的,找一套开源的代码修改一下就可以完成需求.
但是这个还是要根据产品需求去改，同时也需要维护。
小广告，欢迎大家关注我的专栏：小朔哥的Java路
里面多个大咖面试经历，各种干货，欢迎关注，也欢迎投稿。
一直以来，Java都是主流的开发语言，出现二十多年以来，Java依然拥有世界上数量最多的程序员，在编程语言的鄙视链条上也一直处于顶端
这一点在大厂面试中同样体现的淋漓尽致，很多人在面试谷歌、亚麻等大厂的时候，都会被要求Java优先。点开谷歌亚麻等大厂软件工程师岗位的招聘，Java的出现频率高达90%。
确实，根据最新统计的编程语言岗位数量及薪资对比Java的职位空缺数量始终排行第一
就业市场上对Java的招聘需求，达到了总需求量的60%到70%，平均薪资也是位列前列是最容易找到高薪工作的编程语言之一。
为什么大厂都偏爱Java？
作为一种面向对象的编程语言，Java的可移植性比较高，最初设计时就是本着一次编写到处执行设计的，可以用来开发各种应用程序和游戏。
而且，经过了长达24年的积淀，这一个语言已经有了很多的使用实例可供参考，并且能够跨平台使用，这让它在变得越来越难以取代，这也是Java能受到各家大厂青睐的原因。
刷题的天选语言
当然，对求职者来说，Java的确是刷题的“天选语言”。就拿三种最常被用来刷题面试的语言对比：
- C++：主要应用于无人驾驶方面，和一些底层方面，还有金融等；
- Python：主要侧重于Data Science，所以如果往这方面方向发展，选择python比较好；
除了这些特定领域外，剩下就全是Java的天下了，毕竟，市面上Java 和上面两门语言的比例大概为 6:2:2 左右。所以，如果要把刷题和工作联系起来，那还是选择Java吧。
论学习成本，C++ > Java > Python，用C++刷题会遇到很多语言坑，考虑的东西比其他两个多太多，面试一紧张指针引用地址搞错了崩了就惨了；Python刷题简单，但不能不承认在以后工作中适用范围比较窄，所以可以用作入门，但不能作为全部。
Java入门方法
推荐一个国外大佬的Java学习路线：
有条件的可以看看完整视频：油管链接
Then，Java相关学习资源，请收好~
Java学习网课资源
CodeGym ：一个在线Java编程课程，80%的内容是练习，适合一窍不通的入门者。
Wibit Online Java Courses ：一个非常有趣的编程学习网站，各种生动的动画形象能让人忘记学习的枯燥。在线视频学习，非常适合零基础。
stanford CS106A: Programming Methodology ：斯坦福经典课程系列，完全没有编程经验，想学Java语言的，可以看看这个课程。
Bloombenc ：一个在线交互式学习平台，老师可以根据你的学习能力和节奏修改他们的教学方法，还可以在平台上编码。
CodeAcademy ：比较实用的Java在线课程，注重的是在找工作时非常有用的技术能力。
PLURALSIGHT：整合了很多Java的视频课程，部分免费，部分付费，可以根据自己的需要挑选。
Lynda Online Java Training Videos：Java进阶课程，包括如何使用JDBC来集成MySQL数据库，Reflection API，管理文件和目录等。
九章基础算法班（Java）：中文在线互动课，随时开始学习。是Java和算法的结合课程，由硅谷资深Java工程师讲授，非常适合从零开始学习Java、算法与数据结构，或有转专业找工作需求的小伙伴们。
Java学习相关网站
BeginnersBook：Java初学者免费教程，有稍微一些编程基础之后，可以跟着文档里的代码练习。
docs.oracle.com/javase/tutorial：官方Java指南，对了解几乎所有的java技术特性都非常有帮助。
JournalDev：Java相关教程及问答
JavaWorld：最早的一个Java站点，每周更新Java技术文章。
developer.com/java ：由http://Gamelan.com 维护的Java技术文章网站。
IBM Developerworks技术网站：IBM的Develperworks技术网站，这是其中的Java技术主页
Java书籍推荐
Java语言本身：
入门
《Head First Java》
真正的入门书籍，轻松搞笑，可以通过玩游戏、拼图、解谜题以及一些意想不到的方式与Java交互，再也不怕“从入门到放弃”。
如果你没有学过其他语言亦或是转行到计算机行业，可以先看看这本书。这本书图文并茂条理清晰，非常容易理解，练习也足够，可以让你一口气读很久而不会觉得有什么地方遗漏或者根本没记住。而且这本书可以让你从语言基础开始一直学习到包括线程、网络与分布式程序等项目，最重要的是，你将学会如何像个面向对象开发者一样去思考。
《疯狂Java讲义》
可以算是国人原创必读经典了，同样非常适合初学者。讲解内容细致全面，系统通俗，目录划分和查找非常方便，就算完全没有基础也可以学的没有什么压力。同时这本书还考虑了Java的版本升级，非常贴心。
进阶
《Java编程思想》
这是一本所有的Java学习者都无法避开的经典之作，被誉为全球最好的Java书籍。不同水平的人读这本书也会有不同的感觉，初学Java的时候也许会觉得学的非常慢，当你编程了一段时间之后再看这本书，你就会发现，你编程中遇到的问题在这本书中有很多的体现，这时候大概就是你进阶的时候了，你读这本书也会变得比从前轻松和愉快了。编程几年之后再看这本又会是怎样的感觉呢？不妨拭目以待。
《Java核心技术》
作为与《Java编程思想》齐名的大全式图书，这本书的内容更加细致，偏重与讲解Java计数，举例说明了大量API，内容翔实、客观准确，不拖泥带水，所以相比于《Java编程思想》，更注重于实用性。而且这本书全面而且易懂，放在案旁用到的时候查一查、看一看，也是Java初学者和Java程序员的必备参考书。
《Effectice java》
谷歌首席架构师的大作，也是一本经典。介绍了在Java编程中78条极具实用价值的经验规则，揭示了应该做什么，不应该做什么才能产生清晰、健壮和高效的代码，并通过例子代码加以进一步说明，这些经验规则涵盖了大多数开发人员每天所面临的问题的解决方案。
初学者读这本书可能没有太深的体会，当你有那么一两个项目的经验，再读这本书，就会发现书中提到的某个规则就是你在很多次工作经验后总结出来的最准确的描述方式
不过，这本书的中文版翻译不太好，有能力的话可以看原版。
《Java性能权威指南》
Java性能方面可能最好的一本书。深入介绍了JIT编译器、垃圾收集算法、线程同步等复杂问题，讲解了很多应用性能分析以及优化的方法，详尽讲解了Java性能调优的相关知识，帮助读者深入理解Java平台性能的各个方面，适合所有想了解性能优化的Java程序员。
以上是一些基于Java语言本身的书籍推荐，然而，作为一名工程师，从编写可读的代码，到重构现有的代码，再到设计模式，是编码的必备法则。
重构与设计模式：
《HeadFirst 设计模式》
HeadFirst 系列的另一本书《HeadFirst 设计模式》，同样是一本非常适合入门设计模式的书籍，没有之一。这本书介绍 了23 个设计模式，同样采用场景对话、打比方的方式来讲解，巧妙地让设计模式的理论在实际应用中体现出来，淡化了抽象性。
《设计模式》
设计模式领域的开山鼻祖，必读，并且值得多读几遍。虽然其中的例子是C++写的，但也很适合Java学习者读。
《设计模式解析》
如果你觉得《设计模式》太晦涩难懂，《Head First Design Pattern》又太不技术书籍了，那么这本《设计模式解析》就非常适合你。本书每章结束时都有小结和启发性复习题，可以帮助你更好地了解自学得如何了。而且这本书只介绍了几种比较常用简单的设计模式，因而在学习过程中会很有成就感。
《重构: 改善既有代码的设计》
好的代码是重构出来的，而不是一开始就写出来的，除非你的代码不用于任何业务。本书从一个重构实例开始，用代码和实例配合讲解了各种耳熟能详的重构方法，非常到位，总之，是一本程序员必读书目，书中的示例代码都是java写的。
《代码整洁之道》
篇幅不大，但却能让人受益匪浅。书中给了很多方法与规范，遵循它们可以写出整洁的代码。如何为函数，变量，类型准确的命名，如何减少注释做到代码即文档，如何通过良好的编程规范减少错误的代码等等，这些都需要在工作学习中总结经验形成习惯。
最后，献上一张Java技能图谱：
九章算法，硅谷一线工程师在线直播授课，已经帮助30000+人成功拿到心仪offer。
九章基础算法班（Java），零基础转专业找工作必备现，针对知乎用户推出限时免费，原价US$101.68（￥666）现在邀请一名好友共同报名，即可免费学习。添加微信jiuzhang6，回复“知乎Java”领取全额课程抵价券。
更多课程信息请访问：九章算法
