程序员高并发面试题

① java程序员面试时被问到：如何在j2ee项目中处理高并发量访问 该怎么回答 请仔细看题干再回答

尽量使用缓存，包括用户缓存，信息缓存等，多花点内存来做缓存，可以大量减少与数据库的交互，提高性能。

② 你怎么看待满嘴高并发，编码能力却稀松平常的程序员

我是搬砖哥我来回答。

高并发的核心原理，是网络io的事件处理机制，就细节来说，一些重要环节，比如协议的断包组包处理，还是比较复杂的，但就大部分的面试和日常工作来说，做到切实理解reactor机制的核心，就差不多了。关于高并发，可以多看下陈硕的那本书。

关键问题在于如果编程能力很稀松，那么问题很大，简单说交给一个任务，或者解决一个问题，动手能力弱的话，可能会久搞不定，还容易出错。对于开发岗位来说，现在公司不论大小，日常工作不会有特大难度或规模的开发，换句话说谁的基本功更过硬，谁的任务往往完成的又快又好。

动手能力弱有个特别简单直接的改进方法，就是刷leetcode之类，把代码先写起来。不论什么语言，先多写，写的多了自然不会稀松。

然后从简单面向对象到最基础的两三个设计模式，串行到并行，结合自己的编程语言，把语言的特性逐渐吃透，过程也是和刷题一样，写代码不断加深印象。包括学一门新的编程语言也是如此。

对大多数人来说，达到编程高手都不容易，但达到合格员工完全可以的，付出够的努力即可，好脑子不如烂笔头。

如果压根就没有接触过高并发系统，或者连百万级用户的系统都没负责过，就不要谈高并发。因为，99%的程序员都接触不到高并发系统。

高并发这个词语对于我，或者说对于我的项目组一点不陌生，因为我们做的是真正的高并发系统，当 然不是那么的“高”，算是一般高并发吧！集群的QPS在15万左右。

高并发系统面临的另外一个问题就是“高”的倾斜性。 根据“二八”原则，80%的请求都发生在20%的时间内 。也就是说，系统只有在20%的时间面临高并发请求，其余时间并非高并发请求。而这种情况下，我们就要做好系统的弹性扩容伸缩。我们可以根据前置负载均衡器的QPS（SLB）、CPU等指标弹性的扩容或者收缩机器。这样，当请求量大的时候，我们就自动扩容更多的机器来处理请求，当请求少的时候，我们就收缩机器，降低成本。

总之，高并发系统所涉及到技术是非常复杂的。 如果想侃侃而谈高并发概念，必须要亲身实战过高并发业务 。通过高并发业务的实操，我们能更深的理解高并发的精髓。至于，编码...我觉得是最底层的工作，只要思路清楚，写代码就是个体力活。

面试造航母，工作拧螺丝

给我第一感觉是这人可能培训班出来的，因为培训班天天拿这些来忽悠人，90%以上的的公司都没什么高并发，说这些无非显得自己很牛逼，我对这种人都笑笑而已，同行之间都知根知底，忽悠外行吧！

高并发怎么做？把别人写好的框架，多配置几个线程，内部代码基本还是单线程处理逻辑，最多做个互斥锁，遇到高并发就选择非并发的服务器或者组件来避开，然后数据分发给多线程。

现在有多少人自己写并发的？很少了

不会高并发。

自己写了个框架，2000一年的入门服务器。可能也就只能顶几百并发吧。然后拿去做了个项目，后来法律出来了，停了不做了。

不过如果从技术角度看，要15万的并发，快速的做法就是上硬件负载均衡。然后堆服务器，数据直接进内存数据库，后台慢慢进关系数据库。

毕竟我这边就一个人，短时间要上大并发，还是用设备顶省事。

背的面试题呗。

现在招聘，尤其是互联网公司招聘，一看学历是否符合，二看面试题背的是不是6。

至于写普通代码的能力，who cares ，反正进去是上螺丝。

张嘴就来高并发，一开始是由培训班带来的风气，他们这样做主要是为了吸引生源，后来慢慢的就转变成面试内容，90%的应用开发都没有高并发

我很少会说高并发，但是我会经常说并发编程，两个概念。高并发涉及到的知识点太多了，不光是并发编程这一块。而且一般公司也用不到高并发。不过并发编程就不一样了，并发编程还是很多项目会用到的。所以，切合实际，可以从并发编程入手。

都是为了找工作，没啥好说啊！只能说成年人的世界没有容易二字。

③ 在国企当程序员是什么体验

乐字节教育 是集线上教育与线下培训于一体的全栈式教育机构，致力于高端IT技术教育，培养高端IT人才，让人人都享有高品质教育是乐字节的教学理念。

2017年初，我通过一整天的笔试及面试加入一家（某一线城市国资委全资控股）某集团的研究机构（中央研究院），任职软件工程师！

在这边工作了整整一年，目前 已经跳槽到一家互联网公司 ，在回头看看这一整年，感受颇深，只好一吐为快，以便对想进入国企的程序员帮助及借鉴。

入职考试

国企面试与其他企业并没有太大区别。

首先是笔试，一般都是前面50道选择题，后面两道是开放性的大题，大题没有固定答案，只要符合社会主义核心价值观就可以拿到满分。

选择题是关键，全部都是技术题，需要答对40题以上，才有可能进入下一轮面试。

面试分三轮， 首轮是程序员面你（你未来的同事） 。

他们会问你一些技术相关问题，例如：选举算法，redis的应用场景，如何处理高并发，如何保证高可用，是否关心Nodejs新发布的版本，deno是什么；诸如此类的问题很多很杂。

第二轮面试是由副院长来面（也就是你未来的直属上司） 。

他会问你项目相关的问题，例如：做过哪些项目，解决了什么问题，你在项目中的角色，项目是如何管理的，又是如何进展的，使用了哪些技术栈，为什么挑选这样的技术栈，遇到哪些问题，如何解决的这些问题。

第三轮面试是由HR来面 。

这个面试就很简单了，简单说一下你的情况，聊聊家常，然后他会向你说明组织结构，与一些待遇问题。

PS：进国企最重要的素质是文凭，我们研究院硕士以上学历人数比本科要多，而且大部分毕业于国内一流院校（交大生是整个研究院的主体）。

入职国企工作

1、工作压力

工作压力还是蛮大的，产品并不像私企由市场导向，而是政策导向；国家说人工智能热，那我们就去做人工智能的项目，说区块链热，我们就去搞区块链的项目，反正我在研究院一年以来，搞过云计算，人工智能，大数据，区块链。

好处就是你能学到很多东西，而且紧跟市场热度。坏处就是什么都会，但是什么都不精。

举个两个例子，我们也开发OCR AI图片识别系统，在市场上已经有很完善的产品，而且很廉价，我们依然花钱去开发这种产品，市场价值基本没有，因为直到目前为止，我们产品的识别率依然不如市场上的几个主流产品（阿里，网络）。

第二个例子，便是私有云，这个我们做得真的还不错，但是市面上最强的是华为，他们是卖服务器送私有云，也就是传统的卖硬件送软件，与他们相比，我们的产品就不具竞争力了。

工作强度真的还好， 一般都不需要加班 ，至少我是不加班的。

这就意味着可以放羊了吗？当然不是！

我加入的项目组，大多都是以2个星期为周期进行开发的，每两个星期要举行一次组内讨论会，如果完不成任务或者bug太多是需要加班处理的，因为国企是不可以出错的，一次出错可能直接招致点名批评（包括这个项目的所有相关人员）， 一次KPI黑记录，会直接影响你以后的升迁前途 。

组内都是协同工作，可能因为你的原因导致项目没法按时上线，发生一两次你就会被边缘化，最终要么离职，要么下放到子公司。 就算是副院长级别，如果完成不了集团的KPI，也是会被下放的。

但是相比互联网公司，国企的压力相对小一些，互联网公司实行的是不能胜任就走人的策略，所以每个人几乎都没有什么安全感，只有拼命的工作来争取自己有安全感。

国企，特别是大国企，公司的人事权一般都在公司总部手里。

国企办公环境一般都是比较好的，我们有自己的园区，自己的办公楼，空间很大，硬件配置都是很不错的，有健身器材，有空气净化器，有自己的食堂，有自动售货机。

有自己的产品展厅，有自己的公司纪念馆。

这部分只剩下吐槽了， 一个萝卜一个坑，萝卜不走，也不会让出这个坑 。在国企表现是没有意义的，除了口头表扬，你获得不了任何实际好处。

好的人脉要比努力重要，如果上面没人认识你，就算你的领导大力推荐你，你也不会得到提拔，空降长官在国企是一件司空见惯的事。

PS：组织人员要比群众晋升快（群众进不了总部）。

如果说国企15年前的待遇是一流的，那么 如今的国企待遇最多只能算是二流的，特别是对于IT行业来说。

以我所在公司为例，待遇采用工资+福利（洗漱产品，电影票，接近1500元人民币的补助等）的方式，工资增长比较慢，相对于互联网公司来说，待遇至少是被腰斩的，鄙人也是迫于生活压力，为了生计而离开国企，跳槽去了互联网公司。

吐槽****：****国企没有奖金，国企没有奖金，国企没有奖金 ，重要的事情说三遍。

国企的稳定性应该是最被人人称道的，特别是中字头企业。

一方面是国企的社会责任感几乎不太可能会裁员；另一方面公司的人事权几乎都是在公司总部手中，下面的分部门是没有权利做出裁员决定的。

以研发为例，如果有人不能胜任工作或者和其他人工作合不来，部门领导会想总部申请调岗，调到行政人力或其他部门，不会出现领导向总部申请把你开除的事，所以国企给了员工很大的安全感。

互联网公司则不同，裁员是家常便饭，领导一高兴或一生气甚至一拍脑袋就裁员，经常一年就会裁员几次，员工几乎是没有安全感的。

互联网公司很多都是靠融资生存，一旦融资间隔比较大或融不到资就会裁员，生存的压力巨大，让它们没有能力或者没有职业道德感或无耻去考虑员工的感受。

国企则不同，国企的业务本来波动就很少，国企营收相对稳定，再说也不差钱，没有生存的压力。

实际大部分国企使用的技术一般都是商用的，比如Oracle，SQL server等，极少使用网上的开源框架。

一方面是因为商业软件系统稳定，有大公司做技术支持；另一方便开源软件稳定性有待加强，到了线上因为开源框架的bug导致的系统故障可以说是得不偿失，毕竟对于国企来说不差这些钱。

但是我们不同，我们毕竟是研究院，以研发为主，所以更多地使用开源技术。

PS：国企软件开发版本迭代比较慢，系统测试时间比较长，毕竟对于国企来说，不怕慢，就怕系统出现问题，系统出了问题比系统开发不出来更严重。

④ 程序员是干什么的

程序员(英文Programmer)是从事程序开发、程序维护的专业人员。一般将程序员分为程序设计人员和程序编码人员，但两者的界限并不非常清楚。软件从业人员分为初级程序员、中级程序员、高级程序员(现为软件设计师)、系统分析员，系统架构师，测试工程师六大类。

职责

1、对项目经理负责，负责软件项目的详细设计、编码和内部测试的组织实施，对小型软件项目兼任系统分析工作，完成分配项目的实施和技术支持工作。

2、熟悉并熟练掌握交付软件部开发的软件项目的相关软件技术。

3、负责向项目经理及时反馈软件开发中的情况，并根据实际情况提出改进建议。

4、参与软件开发和维护过程中重大技术问题的解决，参与软件首次安装调试、数据割接、用户培训和项目推广。

5、负责相关技术文档的拟订。

简单来说，就是写代码的。

⑤ 高并发，你真的理解透彻了吗

高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。

在过往的面试中，如果候选人做过高并发的项目，我通常会让对方谈谈对于高并发的理解，但是能系统性地回答好此问题的人并不多。

大概分成这样几类：

1、对数据化的指标没有概念 ：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等关键数据。

3、理解片面，把高并发设计等同于性能优化 ：大谈并发编程、多级缓存、异步化、水平扩容，却忽视高可用设计、服务治理和运维保障。

4、掌握大方案，却忽视最基本的东西 ：能讲清楚垂直分层、水平分区、缓存等大思路，却没意识去分析数据结构是否合理，算法是否高效，没想过从最根本的IO和计算两个维度去做细节优化。

这篇文章，我想结合自己的高并发项目经验，系统性地总结下高并发需要掌握的知识和实践思路，希望对你有所帮助。内容分成以下3个部分：

高并发意味着大流量，需要运用技术手段抵抗流量的冲击，这些手段好比操作流量，能让流量更平稳地被系统所处理，带给用户更好的体验。

我们常见的高并发场景有：淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事情，每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等，都可以归为高并发。

很显然，上面谈到的高并发场景，并发量各不相同， 那到底多大并发才算高并发呢？

1、不能只看数字，要看具体的业务场景。不能说10W QPS的秒杀是高并发，而1W QPS的信息流就不是高并发。信息流场景涉及复杂的推荐模型和各种人工策略，它的业务逻辑可能比秒杀场景复杂10倍不止。因此，不在同一个维度，没有任何比较意义。

2、业务都是从0到1做起来的，并发量和QPS只是参考指标，最重要的是：在业务量逐渐变成原来的10倍、100倍的过程中，你是否用到了高并发的处理方法去演进你的系统，从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题？而不是一味的升级硬件、加机器做水平扩展。

此外，各个高并发场景的业务特点完全不同：有读多写少的信息流场景、有读多写多的交易场景， 那是否有通用的技术方案解决不同场景的高并发问题呢？

我觉得大的思路可以借鉴，别人的方案也可以参考，但是真正落地过程中，细节上还会有无数的坑。另外，由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致，这些都会导致同样的业务场景，就算用相同的技术方案也会面临不同的问题，这些坑还得一个个趟。

因此，这篇文章我会将重点放在基础知识、通用思路、和我曾经实践过的有效经验上，希望让你对高并发有更深的理解。

先搞清楚高并发系统设计的目标，在此基础上再讨论设计方案和实践经验才有意义和针对性。

高并发绝不意味着只追求高性能，这是很多人片面的理解。从宏观角度看，高并发系统设计的目标有三个：高性能、高可用，以及高可扩展。

1、高性能：性能体现了系统的并行处理能力，在有限的硬件投入下，提高性能意味着节省成本。同时，性能也反映了用户体验，响应时间分别是100毫秒和1秒，给用户的感受是完全不同的。

2、高可用：表示系统可以正常服务的时间。一个全年不停机、无故障；另一个隔三差五出线上事故、宕机，用户肯定选择前者。另外，如果系统只能做到90%可用，也会大大拖累业务。

3、高扩展：表示系统的扩展能力，流量高峰时能否在短时间内完成扩容，更平稳地承接峰值流量，比如双11活动、明星离婚等热点事件。

这3个目标是需要通盘考虑的，因为它们互相关联、甚至也会相互影响。

比如说：考虑系统的扩展能力，你会将服务设计成无状态的，这种集群设计保证了高扩展性，其实也间接提升了系统的性能和可用性。

再比如说：为了保证可用性，通常会对服务接口进行超时设置，以防大量线程阻塞在慢请求上造成系统雪崩，那超时时间设置成多少合理呢？一般，我们会参考依赖服务的性能表现进行设置。

再从微观角度来看，高性能、高可用和高扩展又有哪些具体的指标来衡量？为什么会选择这些指标呢？

2.2.1 性能指标

通过性能指标可以度量目前存在的性能问题，同时作为性能优化的评估依据。一般来说，会采用一段时间内的接口响应时间作为指标。

1、平均响应时间：最常用，但是缺陷很明显，对于慢请求不敏感。比如1万次请求，其中9900次是1ms，100次是100ms，则平均响应时间为1.99ms，虽然平均耗时仅增加了0.99ms，但是1%请求的响应时间已经增加了100倍。

2、TP90、TP99等分位值：将响应时间按照从小到大排序，TP90表示排在第90分位的响应时间， 分位值越大，对慢请求越敏感。

3、吞吐量：和响应时间呈反比，比如响应时间是1ms，则吞吐量为每秒1000次。

通常，设定性能目标时会兼顾吞吐量和响应时间，比如这样表述：在每秒1万次请求下，AVG控制在50ms以下，TP99控制在100ms以下。对于高并发系统，AVG和TP分位值必须同时要考虑。

另外，从用户体验角度来看，200毫秒被认为是第一个分界点，用户感觉不到延迟，1秒是第二个分界点，用户能感受到延迟，但是可以接受。

因此，对于一个 健康 的高并发系统，TP99应该控制在200毫秒以内，TP999或者TP9999应该控制在1秒以内。

2.2.2 可用性指标

高可用性是指系统具有较高的无故障运行能力，可用性 = 正常运行时间 / 系统总运行时间，一般使用几个9来描述系统的可用性。

对于高并发系统来说，最基本的要求是：保证3个9或者4个9。原因很简单，如果你只能做到2个9，意味着有1%的故障时间，像一些大公司每年动辄千亿以上的GMV或者收入，1%就是10亿级别的业务影响。

2.2.3 可扩展性指标

面对突发流量，不可能临时改造架构，最快的方式就是增加机器来线性提高系统的处理能力。

对于业务集群或者基础组件来说，扩展性 = 性能提升比例 / 机器增加比例，理想的扩展能力是：资源增加几倍，性能提升几倍。通常来说，扩展能力要维持在70%以上。

但是从高并发系统的整体架构角度来看，扩展的目标不仅仅是把服务设计成无状态就行了，因为当流量增加10倍，业务服务可以快速扩容10倍，但是数据库可能就成为了新的瓶颈。

像MySQL这种有状态的存储服务通常是扩展的技术难点，如果架构上没提前做好规划（垂直和水平拆分），就会涉及到大量数据的迁移。

因此，高扩展性需要考虑：服务集群、数据库、缓存和消息队列等中间件、负载均衡、带宽、依赖的第三方等，当并发达到某一个量级后，上述每个因素都可能成为扩展的瓶颈点。

了解了高并发设计的3大目标后，再系统性总结下高并发的设计方案，会从以下两部分展开：先总结下通用的设计方法，然后再围绕高性能、高可用、高扩展分别给出具体的实践方案。

通用的设计方法主要是从“纵向”和“横向”两个维度出发，俗称高并发处理的两板斧：纵向扩展和横向扩展。

3.1.1 纵向扩展（scale-up）

它的目标是提升单机的处理能力，方案又包括：

1、提升单机的硬件性能：通过增加内存、 CPU核数、存储容量、或者将磁盘 升级成SSD 等堆硬件的方式来提升。

2、提升单机的软件性能：使用缓存减少IO次数，使用并发或者异步的方式增加吞吐量。

3.1.2 横向扩展（scale-out）

因为单机性能总会存在极限，所以最终还需要引入横向扩展，通过集群部署以进一步提高并发处理能力，又包括以下2个方向：

1、做好分层架构：这是横向扩展的提前，因为高并发系统往往业务复杂，通过分层处理可以简化复杂问题，更容易做到横向扩展。

上面这种图是互联网最常见的分层架构，当然真实的高并发系统架构会在此基础上进一步完善。比如会做动静分离并引入CDN，反向代理层可以是LVS+Nginx，Web层可以是统一的API网关，业务服务层可进一步按垂直业务做微服务化，存储层可以是各种异构数据库。

2、各层进行水平扩展：无状态水平扩容，有状态做分片路由。业务集群通常能设计成无状态的，而数据库和缓存往往是有状态的，因此需要设计分区键做好存储分片，当然也可以通过主从同步、读写分离的方案提升读性能。

下面再结合我的个人经验，针对高性能、高可用、高扩展3个方面，总结下可落地的实践方案。

3.2.1 高性能的实践方案

1、集群部署，通过负载均衡减轻单机压力。

2、多级缓存，包括静态数据使用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。

3、分库分表和索引优化，以及借助搜索引擎解决复杂查询问题。

4、考虑NoSQL数据库的使用，比如HBase、TiDB等，但是团队必须熟悉这些组件，且有较强的运维能力。

5、异步化，将次要流程通过多线程、MQ、甚至延时任务进行异步处理。

6、限流，需要先考虑业务是否允许限流（比如秒杀场景是允许的），包括前端限流、Nginx接入层的限流、服务端的限流。

7、对流量进行 削峰填谷 ，通过 MQ承接流量。

8、并发处理，通过多线程将串行逻辑并行化。

9、预计算，比如抢红包场景，可以提前计算好红包金额缓存起来，发红包时直接使用即可。

10、 缓存预热 ，通过异步 任务 提前 预热数据到本地缓存或者分布式缓存中。

11、减少IO次数，比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。

12、减少IO时的数据包大小，包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。

13、程序逻辑优化，比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化，或者采用更高效的算法。

14、各种池化技术的使用和池大小的设置，包括HTTP请求池、线程池（考虑CPU密集型还是IO密集型设置核心参数）、数据库和Redis连接池等。

15、JVM优化，包括新生代和老年代的大小、GC算法的选择等，尽可能减少GC频率和耗时。

16、锁选择，读多写少的场景用乐观锁，或者考虑通过分段锁的方式减少锁冲突。

上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点，需要有配套的监控系统实时了解当前的性能表现，并支撑你进行性能瓶颈分析，然后再遵循二八原则，抓主要矛盾进行优化。

3.2.2 高可用的实践方案

1、对等节点的故障转移，Nginx和服务治理框架均支持一个节点失败后访问另一个节点。

2、非对等节点的故障转移，通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。

3、接口层面的超时设置、重试策略和幂等设计。

4、降级处理：保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。

5、限流处理：对超过系统处理能力的请求直接拒绝或者返回错误码。

6、MQ场景的消息可靠性保证，包括procer端的重试机制、broker侧的持久化、consumer端的ack机制等。

7、灰度发布，能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。

8、监控报警：全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

9、灾备演练：类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。

高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。

3.2.3 高扩展的实践方案

1、合理的分层架构：比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。

2、存储层的拆分：按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。

3、业务层的拆分：最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5 ）。

高并发确实是一个复杂且系统性的问题，由于篇幅有限，诸如分布式Trace、全链路压测、柔性事务都是要考虑的技术点。另外，如果业务场景不同，高并发的落地方案也会存在差异，但是总体的设计思路和可借鉴的方案基本类似。

高并发设计同样要秉承架构设计的3个原则：简单、合适和演进。"过早的优化是万恶之源"，不能脱离业务的实际情况，更不要过度设计，合适的方案就是最完美的。

作者简介：985硕士，前亚马逊工程师，现大厂技术管理者。

⑥ 大四毕业生但是毫无项目经验的程序员该如何提高自己

要快速提升自己的话，就要懂得该怎样去学习，掌握学习方法是很重要的。如果你没有一点编程基础，我建议你从c语言开始学起，为什么这么说呢？因为c语言是所有编程语言的基础，学会了c语言的编程思想之后，任何一门编程语言你都可以自己去学习了。在初学任何一门学科时，建立信心非常重要，所以在初学一个知识点时，你就老老实实的跟着教材的思维走，不要思考、不要较劲，你在初学时就是要接受而不是推敲。在这个时候，你还没有任何基础，你在思考和推敲的过程很容易受挫，如果你经常受挫，过不了一段时间你就会对这个学科产生了恐惧，害怕去学习，这样就很容易半途就自我放弃了。在第一次学习某个知识点，你的核心就是两个字“接受”，相信我，这会让你受益的。

⑦ 你身边有离开大厂进工厂的程序员吗他们都是怎么想的

今天好多人在讨论程序员离开大厂进工厂，越来越多高学历人才加入制造业，如何看待这一趋势，会带来哪些变化？这一话题

好多网友说终于觉醒了，制造业才是根本！

这就有点标题党了，怕是对宁德时代有什么误会。

所谓的工厂不是我们平常认知的那种中小型工厂

他们进去也不是做拧螺丝的普通工人，基本都是做工程师的那种技术猿！

既然都是技术精英在哪里都能发光发热也是正常的，而且it也是分为好多类型的，在大厂里也有做基础工作的熬夜加班工地人呢。

不要对互联网有深厚的偏见，更不能对制造业有偏见。制造业是经济基础，但是互联网改变了物质的流通速度和形式，是生活的基础。

就现在的情势而言，我觉得已经没什么蓝领，白领，金领之分了。

能够赚钱生活，能够学以致用，才是王道！

这里的学不仅是知识，还包括技能，职业技能，所以不仅高素质人才进入制造业值得赞许，同时，那些在基础岗位任劳任怨的真工人更应该得到一份尊重和赞美！

在任何岗位上勤勤恳恳发光发热的大家，都是社会建设积极向上的一份子！

⑧ 北漂女程序员工作7年来面试要价26K，该不该要她

前段时间面试了一位程序媛，差不多下午3点左右来我们部门面试，于是老板喊人接待了她，我们来简单看看这位程序媛的简历吧。

提前说明这篇文章只是为了帮助大家应聘时应该注意哪些问题，可以跟自己的简历对比下，找找差距，也是帮助大家。

姓名：张xx

性别：女

出生日期：1992年6月

民族：汉

籍贯：山东

工作意向：Java开发

教育背景：西安电子科技大学 软件xx专业

至于邮箱和QQ，电话这些，就不透露了。

● 熟悉spring mvc 、spring、mybatis 等框架

● 熟悉 redis 、rocketmq、bbo、zookeeper、netty 、nginx、tomcat、mysql。

● 阅读过juc 中的线程池、锁的源码以及netty 中的主从多线程源码。

● 了解 spring boot、spring cloud 、elasticsearch 、kafka 等。

● 了解jvm 的内存模型、类加载机制等相关知识

整理了2020年最新大厂面试题。 链接：  点这个，点这个。  暗号：j s，加入即得。

系统为银行客户提供优惠买单功能，激发银行各类卡用户的消费活跃度，以及通过优惠买单为银行拓展新的用户等。系统主要包括商户管理、订单管理、 用户管理、库存管理等子系统。（ssm 、bbo 、rocketmq、redis、jdk1.7、tomcat 8、mysql），系统前后端分离，前端采用vue框架进行开发，后端采用nginx进行负载均衡。

主要负责订单管理系统和库存管理系统接口的开发工作：

1.为手机客户端提供优惠买单接口，并防止商品超卖。

2.使用rocketmq 进行异步化下单，加速高并发下用户的响应速度。

3.使用redis 解决分布式下session 一致性问题。

4.使用mysql 读写分离解决主库读的压力。

系统为运营人员提供公司各类业务数据的查看、统计、商家清算对账等功能。（ssm 、bbo 、rocketmq、redis、jdk1.7、tomcat 8、mysql）

该系统为内部运营人员开发的系统，并发量较小，但是针对各种维度的复杂查询较多，为防止大批量数据查询拖垮核心系统，对服务进行隔离，前端模板引擎采用jsp 进行开发。

1.项目的开发，运维以及部署 。

2.负责mysql 读写分离的设计和实施

3.引入redis、elasticsearch 解决系统响应慢的问题。

工作7年无互联网公司背景、做的项目中使用到的技术还比较前沿，也有一些技术亮点。

不足:两家公司都是非互联网公司，从项目的名字来说，技术点和项目名称不是很匹配。

以上就是她的基本信息，现在我们来看看面试问了些什么。

问：分布式session一致性为何不用nginx iphash？

答：iphash到某个节点，如果改宕机了就不能访问，存在单点问题

问：能举个例子吗？

答：很多小区共用一个IP会导致某台服务器负债压力过大，而其他服务器可能就空闲。

问：标记清除算法讲讲原理和优缺点。

答：效率不高，标记和清除的效率都很低，会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前促发一次GC动作。

问：线程中run结束该线程还能复合吗？

答：不能复活了。

问：那不能复活了，线程池意义何在？

答：当用户提交任务时会检查线程数，如果小于核心数会只用用核心数的线程处理，如果大于核心数就会放到队列里面取，如果队列满了就直接创建，如果创建成功就直接使用，创建失败这会触发拒绝策略。

问：多余的任务放在队列会阻塞吗？工作中什么场景用线程池？

答：是阻塞的…（第二忘记她怎么答得了）

后面还问了zookeeper和eureka区别 IOC 、AOP原理，还考了2个算法题（排序、重复数学题）和一个sql语句题和一个并发原子操作的题。就不一一写出来了，给大家参考一下就行了。

技术面试聊下来感觉技术还不错，虽然项目不突出没有高并发的项目，但是对技术原理和底层还是有一定的理解，沟通表达没问题。技术面的也基本没问题。她要28K，大家觉得在北京高不高？

同时提供【免费】的Java架构学习资料，学习技术内容包含有：Spring，Dubbo，MyBatis, RPC, 源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。

链接：  点这个，点这个。  暗号：js，加入即得。

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。

⑨ 为什么面试都会问下很基础的知识,而实际工作中这些基础根本用不到

中国的软件开发行业,存在一个搞笑的现象,招聘者为了抬高自己的面子,把面试题出得天花乱坠,而实际上他们做的项目却是无比弱智.
仔细分析那些题目,你会发现漏洞百出,破绽百出.以java开发面试,举例如下:
1.关于框架
招聘者:你平时常用哪些框架?
应聘者:在没有甲方和项目经理刻意要求的情况下,基本上不用框架,自己写原生.
招聘者:但是框架可以解决很多问题,比如,spring的面向切面的思想有助于使代码具有更好的可读性和易维护性.
应聘者:如果框架确实能够有效地解决我的问题,我会愿意去学习并且使用它们的.可是,在我之前的开发经历中,还没有遇到过特别棘手的问题.
招聘者:...
2.关于高并发
招聘者:高并发算不算棘手的问题?你怎么应对高并发?
应聘者:线程池加同步队列加拒绝策略,以保护服务器不会瘫痪.
招聘者:你为什么不使用redis来处理高并发?
应聘者:既然java自己已经有能力来解决这个问题了,就没有必要再去求助于别的东西了.
招聘者:...
3.关于数据库
招聘者:你做过mysql优化吗?
应聘者:我不需要做mysql优化.因为mysql+php的时代已经过去了,现在应该属于oracle+java的时代.除非贵公司还做外包项目而不是自主产品.
招聘者:但是这并不意味着java就不能与mysql相配合.
应聘者:我看到甲骨文官方已经明文规定了,java的最佳搭档是oracle,而不是mysql.这是官方的明文规定.
招聘者:...
4.关于即时通信
招聘者:你了解环信或者融云等即时通信吗?
应聘者:听说过环信,没有接触过它.没有听说过融云.
招聘者:那么当你需要主动推送消息的时候,怎么办?
应聘者:开socket长连接,一切实时通信全是基于tcp/ip协议或者ws协议的长连接机制.
招聘者:...
5.关于前端
招聘者:你熟悉前端的js吗?
应聘者:熟悉,js是一种基于对象的语言.
招聘者:为什么是基于对象而不是面向对象?
应聘者:java是面向对象的,其三大特性为:封装,继承,多态.而js是基于对象的,其两大特性为:原型,闭包.这两者完全不是一回事.
招聘者:...
笔者的结论:表面上面试官提出许多足以建造宇宙飞船的问题,现实却是你到了公司里顶多在生产某个不起眼儿的螺丝.当你再去反思那些既可笑又可悲的面试题时,你便会明白那些题目本身是漏洞百出,甚至所谓的架构师的水平根本不如你.他能面试你,而你不能面试他,原因不在于他掌握了技术,而在于他掌握了权力.
每一道题皆反映了该公司当前的状态和困境.他过于强调依赖框架,中间件和第三方服务商,是因为他对于java底层的反射委托调度原理不精通.他使用mysql而不是oracle,是因为此公司的资金不充足,无法为自己的软件产品挑选真正优秀且强壮的数据库.他把面向对象和基于对象两个概念混淆了,是因为他从来没有悟透本质的程序语言和脚本语言的核心内涵.
综上所述,求职者千万不能被企业给糊弄了.归根结底一句话:只要你自己充满了信心,走南闯北都不怕.