|
1 作为一名Java程序员，我为何不在生产项目中转向GO 自Google在2009年发布Go语言的第一个正式版之后，这门语言就以出色的语言特性受到大家的追捧，尤其是在需要高并发的场景下，大家都会想到是不是该用Go。随后，在国内涌现出了一批以七牛为代表的使用Go作为主要语言的团队，而许世伟大神本人也在各种场合下极力推动Go在国内的发展，于是在这种大环境下，中国的Go开发者群体逐渐超越了其他地区。 业余时间好学是一回事，真正要将一个新东西运用到生产中则是另一回事。JavaScript的开发者可以义无反顾地选择Node.js，但是对于Java开发者来说，在下一个大项目里究竟是该选择Go，还是Java呢？ 2 企业级Java应用最重要的4个性能指标 虽然很多人都曾预言Java将一蹶不振，但是不可否认的是，很多重要项目中，尤其是银行和政府一些大型项目，Java仍在其中扮演着极其重要的角色。国内APM领军企业OneAPM的Java工程师陶炳哲，多次参与银行、运营商等大型企业的性能优化工作,总结了企业级Java应用最应重视的4个性能指标，主要包括：商业事务，外部服务，垃圾回收以及应用布局。 3 你的Java代码对JIT编译友好吗？ JIT编译器是Java虚拟机（以下简称JVM）中效率最高并且最重要的组成部分之一。但是很多的程序并没有充分利用JIT的高性能优化能力，很多开发者甚至也并不清楚他们的程序有效利用JIT的程度。 在本文中，我们将介绍一些简单的方法来验证你的程序是否对JIT友好。这里我们并不打算覆盖诸如JIT编译器工作原理这些细节。只是提供一些简单基础的检测和方法来帮助你的代码对JIT友好，进而得到优化。 4 Java大牛谈：我为什么反对用Node 随着无线端的快速普及，前后端分离技术走上前台，而Node由于它的一些特性被工程师快速接受尤其是前端工程师，所以产生了很多Node是否会引起新的技术变革的讨论。 我本人是淘系的一个Web开发人员，基本上经历了淘系关于Node和Java技术选型讨论的过程，所以今天我给大家推演一下在像淘系这个环境下Node能否会成为主流的Web开发技术，当然后面也给出了我认为比较适合的场景。 5 Java永久代去哪儿了 在Java虚拟机（以下简称JVM）中，类包含其对应的元数据，比如类的层级信息，方法数据和方法信息（如字节码，栈和变量大小），运行时常量池，已确定的符号引用和虚方法表。 在过去（当自定义类加载器使用不普遍的时候），类几乎是“静态的”并且很少被卸载和回收，因此类也可以被看成“永久的”。另外由于类作为JVM实现的一部分，它们不由程序来创建，因为它们也被认为是“非堆”的内存。 6 Java9新功能：HTTP2&REPL篇 对Java 9的炒作将不再局限于模块化（modularity），Java 9正在搜罗大量额外的功能模块，这些功能模块正作为Java增强提案（JEP）提交，并在OpenJDK (Java SE的参考实现项目）中实现。 重点关注一些或将在Java 9整个生命周期中，对开发者的工作生活影响最大的JEP，包括新的HTTP/2支持和JShell REPL（读取-求值-打印-循环），后者带来了基于shell的交互式Java开发环境和探索性开发API。 7 简化你的Java代码，让工作更高效 相比于其他程序设计语言，Java语言的冗长已经名声在外。其主要原因是由于程序开发社区中所形成的惯例，在完成任务时，很多情况下，要更大程度地考虑描述性和控制。例如，长期来看，长变量名会让大型代码库的可读性和可维护性更强。描述性的类名通常会映射为文件名，在向已有系统中增加新功能时，会显得很清晰。 如果能够一直坚持下去，描述性名称可以极大简化用于表明应用中某一特定的功能的文本搜索。这些实践让Java在大型复杂代码库的大规模实现中取得了极大的成功。 8 你的Java日志，有没有用这些改进办法 在任何系统中，日志都是非常重要的组成部分，它是反映系统运行情况的重要依据，也是排查问题时的必要线索。绝大多数人都认可日志的重要性，但是又有多少人仔细想过该怎么打日志，日志对性能的影响究竟有多大呢？今天就让我们来聊聊Java日志性能那些事。 9 Java NIO通信框架在电信领域的实践 从广义上看电信软件的范围非常广，细分实际可以分为两大类：系统软件和业务应用软件。 系统软件包括路由器底层的信令机软件、手机操作系统等，业务应用软件主要包括客户关系管理CRM、网上营业厅、融合计费OCS和各类消息网关，例如短信网关、彩信网关等。 本文重点介绍电信业务应用软件的技术变迁历史，以及华为电信软件架构演进和Java NIO框架在技术变迁中起到的关键作用。 10 写代码这回事儿，架构师你可以说不吗？ 要让一个成功的架构得以实现，架构师必须要在整个生命周期始终保持与交付团队的紧密合作。保持紧密合作能够促进架构层面的快速反馈循环。并且还能够为架构师提供更多的与团队交流架构愿景和领导团队的机会。 架构师除了可以参与到实际的编码工作中之外，还有许多其他的方式可以参与到交付团队中，例如结对编程和同行评审。相反，某些参与方式有可能会对团队造成负面影响，例如接管交付、不允许团队自组织或者采用集体所有制。是为了避免“象牙塔”架构师的角色——只在项目最初发布架构，然后就再也不见踪影。 谋求与交付团队的协作关系，共同努力尽早识别和解决架构性缺陷，从而交付成功的架构和最终的产品。 |
|
|
