程序员

Java 面试题 JAVASE 部分 1.什么是重载？ 重载发生在同一类中，指的是对方法的重载，方法名相同，参数列表不同，与方法的返值类型无关，参数列表不同可以是参数的个数不同，也可以是相同位置上的参数的类型不同，与参数的名字无关。 之所以对方法进行重载主要是为了方便程序员的记忆和使用，将功能类似但细节不同的逻辑代码公用一个方法名，方便使用，当程序员在调用时根据细节的不同传入对应方法的参数。 例如打印语句 System.out.println() System.out.println(String str); 这就是方法的重载，前者只打印换行，后者打印字符串后再换行，他们都执行打印和换行操作，不同的是是否有字符串输出 2.什么是重写？ 重写发生在子类和父类之间，是子类对父类的方法的重写，方法名相同，参数列表相同；这里参数列表相同指的是参数的对应位置类型相同且个数相同，与参数的名字无关。 重写可以是对方法的重写，也可以是对成员变量的重写；这里主要介绍方法的重写；重写主要是对父类方法的一个扩展，是对父类方法的一个改造。当子类继承自父类方法后，父类的方法并不能满足子类要实现的功能，子类可以重写父类的方法。 例如 jdbc 中常用的两个传输器对象 Statement 和 PreparedStatement ,PreparedStatement 继承 Staement, 且将

有很多关于前端程序员的调侃，比如“智商很高情商却很感人，思维缜密，极客，加班严重，没有对象只能new一个……”，虽然不是所有前端程序员都是这样，但这也说明了前端程序员这个群体中存在这种情况。我身边的前端程序员小伙伴就有不少这种情况，我认为工作特点影响了这种性格标签。 前端程序员的很多工作都是需要“单打独斗”，任务分工之后每个人要独立完成部分功能设计，相互沟通比其他岗位少很多。小编的这篇文章能对于前端程序员避免愈发孤独的状态很有帮助。 在工作之外，前端程序员和其他职位的同事应该有更多沟通，企业也应该为他们创造更多沟通条件。 有些人认为，前端软件开发者只要会写代码会调试，技术能力够强就行了，不用具备太多软技能，比如在公司扩大自己的关系网络。我认为软技能跟技术技能同等重要。 今天给大家分享了4个重要的软技能 第一个技能：推销你的工作 大多数情况下，管理层都不会直接去判断你所做的技术工作的质量，他们对你的印象都是基于对你的观察，比如通过你跟他们的直接沟通、你的演讲、别人背后对你的议论等，“如果我们想要对自己的职业发展负责的话，就得管理好对自己工作的营销”。 怎么推销自己的工作呢？我认为，要把关键信息跟管理层进行沟通，让他们对你出色的工作表现留有精确的印象。他自己的经验是，把自己在项目中扮演的角色、承担的工作，明确地跟管理层沟通清楚，评估绩效的时候，他会要求共事过的同事直接对他进行评估。

开发者的日常 　　作为一名996的开发者，我几乎每天只有两件事，制造bug和解决bug，这两件事，既替我解决了温饱问题、也替产品经理、测试工程师等一票人解决了吃穿问题。 　　嗯，有人为我这种程序员评了一个等级，我大概是第五等程序员。 　　但是。。。我是真的想写bug吗？。。。并不是。我也渴望能够编写更加优秀的代码，能够掌握更优秀的互联网技术框架、掌握更加优秀的开发方法，但是每天沉迷于搬砖之中不可自拔，哪怕每天认真阅读Robert大叔的《The Clean Code 》，掌握好代码的速度也远远赶不上我写烂代码的速度。 　　好吧，我的工作大概是这样的： 　　~溪源，你那个功能做完了吗？可以发布了么？ 　　~可以发了，啥毛病都没有。 　　~那行，现在发吧。 　　~等下，我又发现了一个bug。 　　~那我等你五分钟。 　　~好的，只剩最后一个bug了，改完这个bug就可以发，就可以下班了。 　　-哎呀，卧槽，怎么天亮了。。 　　~你就不能做一个不写bug的程序员吗？ 　　~对不起，我做不到啊。 　　~为毛啊。 　　~那天我去庙里上香，我虔诚的对菩萨说，菩萨，保佑我成为一个不写bug的程序员吧~ 　　---然后我获得了永生。 　　以上内容纯属虚构，如有雷同，纯属巧合。 中国程序员的现状 　　中国的程序员大概是国内最苦逼的行业之一，每天996，下班还要回家学习各种新技术哪怕是BAT这样的大厂

本文整理自知乎上的同名讨论帖：《为什么有些大公司技术弱爆了？》，版权归原作者所有，原文地址： www.zhihu.com/question/32039226 有网友提问： 今年年初，到一家互联网公司实习，该公司是国内行业龙头。不过技术和管理方面，却弱爆了。那里的程序员，每天都在看邮件，查问题工单。这些问题，多半是他们设计不当，造成的。代码写的一团糟，全是复制粘贴，连作者都没改，大家普遍不写注释，也不格式化，代码歪歪扭扭。 一个项目里，httpclient竟然出现了四种。一种是该公司研发部写的，一种是老版本的开源项目，一种是新版本的开源项目，还有一种是开发人员造的轮子。 打接口请求响应日志，竟然不知道用拦截器。 打错误日志竟然不打上下文信息，每个人一种日志风格，千奇百怪。 许多重要的中间流程，居然不打日志。 idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。 该公司混了两年的程序员，跟快递公司做查询接口，竟然不知道加密运单号。 所有服务间通讯，都没有设requestId，导致跟踪会话很困难。 一个没什么qps的边缘接口，居然做消费者生产者+阻塞队列的异步模式。 显得你技术少是不是。 不知道异步会增加维护成本，提高测试难度吗？ 而且，任务队里没有考虑持久化，赶上发布，丢了好多任务。 读取一个小小的xml和exc配置文件，居然用流式解析，没见过这么二逼的

俗话说：“习惯成自然，自然成人生”习惯对一个程序员的成败极为重要，好习惯可以让一个程序员走向成功，坏习惯就会走向失败！ 慎于说Yes 在没有搞清楚开发需求、任务工作量、团队期望值之前，有前途的程序员不会轻易答应。特别是对于新人来说，比较急于表现自己，对于同事或者老板的工作安排来者不拒，精神可嘉，方法不可取。承诺太多，会出现自己无法按时完成的情况，即使按时完成，也可能没有达到别人的期望值，长期以往别人对你的失望会越来越多。 敢于说No 看起来和第一条雷同，其实细究起来不一样。第二条执行起来比第一条难得多。当遇到明显不合理的要求时，可以考虑拒绝，前提是准备好了全面充分的理由。不要经常说No，但是一旦说了，就要切中要害。有前途的程序员不会闷头干活，知道自己的定位和团队期望，分清楚哪些是不合理的要求，哪些是合理的要求，然后把明显不合理的要求和领导沟通下，取得支持。 构建自己的知识体系 在信息爆炸的年代，碎片化的知识很多，系统学习的时间越来越少，如果没有自己的知识体系，很容易被淹没在知识的海洋中，而且难以记忆。100分程序员推荐的做法，通过Wiki或者其他知识管理工具构建一个知识框架，大的分类可以包括软技能、架构、语言、前端、后端等，小的分类可以更细化。 培养大局观 程序员比较容易陷入的困境是专注于自己的一亩三分地，不关心团队的进度和业绩，也不关心软件的整体架构和其他模块

前言 今年年初来了一家国内某电器大厂，本来技术面试的时候提供的offer说的是架构组岗位，主要是搭建公司平台的基础设施，不会接触业务或者离业务很远，刚开始以为很有技术含量，公司又是大厂，offer就接下来了，但是进来后才知道是业务导向型团队，因为当时面试我的技术经理离职，公司从原来的项目组找项目经理来替代原先架构组领导岗位就由原来的一个项目经理代理 我入职后领导就以熟悉公司为由，安排我去业务组参与了几个月的业务功能开发。所以我就在业务团队和大家打拼了几个月，我换过的公司不多，原先公司都是比较尊重技术人员，因为大家觉得开发岗位工作比较有技术含量，但是我来到这边后让我感觉很惊讶 这边的开发人员地位很低，在团队里面得到的尊重甚至连测试，运维都不如，基本是处于食物链的最底层，更别说熟悉公司业务的产品经理岗位了，这样的环境开始让我很不适应，但是由于家庭等其他原因导致我无法马上离开，所以我一直用观察者的身份在团队中工作，这也让我总结出很多公司不重视技术的原因，也算是扩展自己的视野，增加自己的阅历，我也总结了以下几点和大家探讨和分享，希望可以帮助大家鉴别和选择更加合适自己的地方： 为什么公司不重视技术，没有技术氛围的公司有哪些特征？ 如何避免进入没有技术氛围的团队？ 喜欢技术的但是已经在业务型的团队里的同学如何脱身？ 如何在业务型公司将利益最大化？ 为什么公司不重视技术

每个程序员、或者说每个工作者都应该有自己的职业规划，如果看到这里的朋友没有自己的职业规划，希望你可以思考一下自己的将来。 个人常常思考自己的未来，也从自己的思考中总结出了一些东西，作为第一部分来谈谈。个人认为一名程序员应该有几个阶段（以下时间都算上实习期）： •第一阶段----三年 •我认为三年对于程序员来说是第一个门槛，这个阶段将会淘汰掉一批不适合写代码的人。这一阶段，我们走出校园，迈入社会，成为一名程序员，正式从书本上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等，积累了一定的开发经验，也对代码有了一定深入的认识，是一个比较纯粹的Coder的阶段 •第二阶段----五年 •五年又是区分程序员的第二个门槛。有些人在三年里，除了完成工作，在空余时间基本不会研究别的东西，这些人永远就是个Coder，年纪大一些势必被更年轻的人给顶替；有些人在三年里，除了写代码之外，还热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术，这些人在五年后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向，从一个Coder逐步走向系统分析师或是架构师，成为项目组中不可或缺的人物 •第三阶段----十年 •十年又是另一个门槛了，转行或是继续做一名程序员就在这个节点上

https://www.cnblogs.com/lys_013/p/9605352.html 实战项目中Java heap space错误的解决 部标GPS通讯系统在上线之后，经过不断调试，终于稳定运行一段时间，后来又遇到了Java heap space错误异常！日志如下： 说明系统中有未释放的对象。如何找出这些未释放对象以及监控JVM堆内存，优化代码释放内存对象呢？还有JVM的垃圾回收机制是如何运作的呢？ 首先在系统启动运行的时候打开记录GC详细信息，运行脚本如下： 看看GC详细日志，当GC到13400多次的时候新生代和老生代的堆内存几乎用满了，频繁触发Full GC (Ergonomics) ，直到没有内存空间给新生对象了。所以JVM抛出了内存溢出错误！进而导致程序崩溃。 首先简单了解下JVM垃圾回收机制： 从上图可以看出 GC 的主要收集区域，包括 PSYoungGen（年轻代）、ParOldGen（老年代）、Metaspace（元数据区）。 新生代：新创建的对象都是用新生代分配内存，Eden空间不足时，触发Minor GC，这时会把存活的对象转移进幸存者Survivor区。 老年代：老年代用于存放经过多次Minor GC之后依然存活的对象。 新生代的GC（Minor GC）：新生代通常存活时间较短基于Copying算法进行回收，所谓Copying算法就是扫描出存活的对象

好程序员Java学习路线分享Spring创建Bean的3种方式，本文讲解了在Spring 应用中创建Bean的多种方式，包括自动创建，以及手动创建注入方式，实际开发中可以根据业务场景选择合适的方案。 方式1： 使用Spring XML方式配置，该方式用于在纯Spring 应用中，适用于简单的小应用，当应用变得复杂，将会导致XMl配置文件膨胀 ，不利于对象管理。 <bean id="xxxx" class="xxxx.xxxx"/> 方式2： 使用@Component,@Service,@Controler,@Repository注解 这几个注解都是同样的功能，被注解的类将会被Spring 容器创建单例对象。 @Component : 侧重于通用的Bean类 @Service：标识该类用于业务逻辑 @Controler：标识该类为Spring MVC的控制器类 @Repository: 标识该类是一个实体类，只有属性和Setter,Getter 1 2 3 @Component public class User{ } 当用于Spring Boot应用时，被注解的类必须在启动类的根路径或者子路径下，否则不会生效。 如果不在，可以使用@ComponentScan标注扫描的路径。 spring xml 也有相关的标签<component-scan /> 1 2 3 4 5 6

　　作为一名优秀的开发者，大家都会用到代码托管，我本人用的是github，确实github里面有很多很多开源的项目，所以我们目前的创业项目程序员客栈www.proginn.com都会给开发者展示自己的github账号，个人一直觉得代码虽然不能直接代表什么，但是那个程序艺术的体现，也是所有开发者个人的心血，这里致敬所有的优秀开发者，下面分享一下一些常用的代码托管工具。 　　 1 、GitHub 　　这个我相信百分之九十的开发者都知道，大家说才是真的好。 　　 2 、Gitlab 　　Gitlab好像是Github的弟弟，哈哈，开玩笑，不过支持一切公开和非公开的代码托管。 　　 3 、Bitbucket 　　免费提供团队成员创建无限量的私有代码管理库。但是仅仅支持团队只有五人，个人感觉这个代码托管工具适合核心开发的五人团队进行开发流程化管理以及代码的复查。 　　 4 、开源中国代码托管 　　上面提到的都是国外的代码托管工具，开源中国我相信大家都知道，可以创建很多个项目代码可以公开化也可以私有化。 　　 5 、coding.net 　　Coding一直是国内首屈一指的代码托管工具，功能和开源中国的差不多，口碑方面都做的不错，很多开发者在用。 　　 6 、CSDN代码托管 　　老牌程序员门户CSDN推出的代码托管。 　　 7 、京东代码托管平台 　　京东代码托管平台，开发者用的不是很多