对于最近线上服务以及京东等大型互联网公司对java工程师要求的一些思考
对于最近线上服务以及京东等大型互联网公司对java工程师要求的一些思考
当下线上服务为了减少上线，经常搞成配置化，配置化对于版本以及持续集成本身是很大破坏，对于此，我个人持保留态度，
是反对过多东西进行配置化，其实配置化本身没有什么问题，关键是动态对配置进行修改而没有与代码进行版本关联，但越来越多
人迎合潮流与领导。
对于线上服务，存在定时拉取配置平台配置，一定进行相应检查，只要人配置东西就一定会有问题，或者说容易发生问题，线
上服务重启时，需要稳赢一下，呆一会看一下启动是否成功，一定不要一次全部服务批量重启，出了问题，就完全没法处理了，并且
需要去看一下日志，以及服务状态，都确认没问题后，在进行重启。
对于上边这种问题，加上昨天前边已经发生两次服务启动不起来，一次是全部线上服务不可用，一次是部分，部分并且批量进
行处理，是目前想到的解决此类问题最好的办法。
对于配置化应该有更多思考，而不是人云亦云。不然这件事有什么意义呢？
最近也是在频繁面试招聘，但是从简历以及面试都筛掉了很多人。对于有一定经验Java研发，一些基本技能要求，我的一些
思考。
学习java经常会遇到一个问题，一段时间后没法进行深入，或者是不断在进行业务开发。Excel导入导出以及各种各样业务功能，以及
各种各样功能点开发，这样不能说不对，但是当我们回过头来看发现我们在技术上好像没有什么进步，只是在不断重复自己。
怎么样做技术？怎么样不重复自己？怎么样有进步？是我们应该持续不断思索的问题。
对于做很多业务功能这个没有问题，问题是我们在一直重复我们自己，对于一个业务一个功能，我们应该多想几个怎么做？有没有
更新的方法？有没有重复事情抽象起来去做的方式？有没有用新的技术去做的方式？
对于java技术点掌握的要进行记录整理总结，然后寻找新的问题、新的技术方案去解决问题。进行新的探索，一遍巩固已经掌握技
术体系，并且不断探索新的技术体系。
java一些重要技术点，缓存ehcache、redis 分布式redis方案、rpc、微服务、设计模式、多线程、线程池、消息队列、锁、jdk、
elasticsearch solr lucene、jvm、gc、io BIO NIO AIO等等各种各样技术都可以是我们可以研究和分析的点。
ehcache缓存设计，缓存架构与原理，缓存失效策略，缓存是否存储硬盘，等等。缺少一个细节了解，可能在一些业务场景下都
会导致比如，写外部磁盘写慢导致服务不可用。
redis单机架构是什么？为什么性能这么高？存储策略？集群架构是什么？有哪种集群方式？官方的以及互联网公司集群架构有什
么异同,优劣？redis单点问题有哪些？怎么样避免单点以及热点数据？怎样进行扩容缩容，扩容缩容对线上服务影响怎么样控制到最小？
rpc原理，一个最简单rpc怎么实现，rpc目的作用，可以应用在哪些场景下？微服务注册中心怎么实现，注册中心需要注意什么问
题，注册中心都有哪些实现方式，dubbo架构以及怎么实现，源码读过么？
BIO、NIO、AIO各是什么？有哪些优缺点，一般都用在什么场景下？在哪些实际应用中用过他们？
设计模式有些哪些、在实际项目中用过哪些设计模式、怎么用、为什么应用、继承在哪些场景用过、怎么应用为什么
多线程在哪些场景用过、线程池用过哪个、参数是什么、均有什么意义？为什么用、多线程同步怎么做、CountDownLatch在哪些场景
下使用？
很多时候总是在说工作中用不到，这是听的最多一种说法，有一定道理，但是价值不大。工作中怎么做还是掌握在自己手中，多思考、
多实践，用新的方式、不同的方式去解决过去问题、老的问题，才能不再过去技术圈打转。
对新的技术，应该不断思索，不断尝试，通过书籍以及实战，对新的技术不断深入，深入后进行总结，然后在探索下一个技术。通过这
样一种方式，不断掌握新技术，避免造成永远再用老技术解决老问题，很多事情还在自己处理。
简单问题不能出错，老是在简单问题出错，时间花费在上面，并且人也会慢慢就废掉了。
好的方式、好的方法、勤思考、多实战。
扫码关注