为何许多年写Java的开发者，实则用C思维编程？

Java早就提供了NIO或者更高级的Netty框架来解决这个问题。NIO采用基于通道和缓冲区的模式，支持多路复用，可以在单线程中处理成千上万个连接。这就好比从传统的“柜台服务”升级到了“自助服务”，效率的提升是数量级的。如果你的服务端工程还在使用传统的阻塞Socket， 或者还在为每一个请求分配一个线程，那么无论你的CPU有多快，到头来都会卡在I/O等待上。拥抱NIO， 理解Selector、Channel和Buffer的工作原理，才是Java网络编程的正道，说真的...。

思维惯性的陷阱

摆烂。 这种“C++思维”最典型的表现，就是对底层性能的过度迷恋。很多从C/C++转行过来的Java工程师， 总是对JVM的垃圾回收心存芥蒂，总觉得不自己手动管理内存，心里就不踏实。于是我们经常可以看到一些奇怪的现象：在一个纯Java的业务系统中，突然冒出了一些带有native关键字的方法。

Java这种编程方式更符合人类的思维方式，便于人类编写。庞大的生态系统:Java拥有一个巨大的生态系统，在全世界有超过900万开发者，来日方长。。

并发编程中的“陋习”

除了对内存管理的执念，C++思维在并发编程领域也“流毒甚广”。在C++的世界里线程管理是一件非常原始和痛苦的事情。你需要手动创建线程、处理同步、小心翼翼地避免死锁。这种思维惯性被带到了Java开发中，表现为对JDK并发库的忽视，以及对底层API的滥用，不靠谱。。

不要试图搞“大爆炸”式的重构，业务不会停，时间也不允许。更现实的方式是：从下一个方法开始， 试着把逻辑从Service挪到Entity里；从下一个参数开始，试着用值对象代替String；从下一个表开始，试着先画对象图，再建数据库表。

代码的“贫血”之病

泰酷辣！ 我见过不少项目，在需要处理异步任务时依然习惯性地手动new Thread。这就好比在Swing桌面程序中， 为了实现一个简单的计时器功能，直接在主线程里写死循环，导致UI界面假死，用户体验极差。正确的做法应该是利用Runnable接口，将业务逻辑封装起来然后交给线程池去施行。

Java早已稳坐企业级开发的头把交椅。只是作为一名在代码堆里摸爬滚打了多年的老兵，我时常在深夜的代码审查中感到一种深深的无力感。这种无力感并非来自于复杂的业务逻辑， 也不是来自于晦涩的系统架构，而是来自于一种显而易见的“错位”——明明手里握着的是Java这把面向对象的倚天剑，挥舞出来的却是C++那种面向过程的砍刀招式，我整个人都不好了。。

基础类型依赖症

很多老系统的代码里充斥着一种“基础类型依赖症”。看看这个入参：public void register。这些String和Integer是没有“防御能力”的。手机号格式对吗？邮箱是不是空的？角色类型是不是越界了？如果不封装，你就要在Service的开头写上十几行的StringUtils.isBlank和正则校验。一旦漏写一个，脏数据就进数据库了。

有啥说啥... 尝试用“值对象”来解决这个问题。比如定义一个PhoneNumber类：

public class PhoneNumber {
    private final String number;
    public PhoneNumber {
        if ) {
            throw new IllegalArgumentException;
        }
        this.number = number;
    }
    // ... getter & logic
}

当你把入参改成register时世界清静了。你不需要再校验手机号格式，主要原因是只要能new出来的PhoneNumber对象，一定是合法的。这才是强类型语言该有的平安感。

面向对象的失落

这是可以说的吗？ 好的代码， 不是展现你用了多复杂的技巧，而是让后来者在读代码时能清晰地看到业务的轮廓，而不是一堆混乱的数据操作。别再用C++的思维写Java了让对象活过来让代码回归本真。

写Java多年，我们很容易陷入一种“熟练工”的陷阱。我们熟练地使用各种框架， 打脸。 熟练地写出CRUD代码，却忘记了Java语言本身的魅力——面向对象。

DODAF架构设计：打破传统，重塑软件开发新范式！

DODAF原本是美国国防部提出的一套架构设计方法， 但现在它已经成为了一种广泛应用的思想，影响着整个软件行业。在DODAF中，一个核心的概念就是区分不同的“视角”，从而能够更好地描述复杂的系统，一句话概括...。

NIO与Netty：高性能网络编程的不二法门！

NIO是Java提供的一种新的I/O处理方式， 它采用基于通道和缓冲区的模式，能够支持多路复用，可以在一个线程中处理成千上万个连接。而Netty则是在NIO的基础上进一步封装，提供了一个更加简单易用的高性能网络编程框架，YYDS！。

"贫血模型"的危害

"贫血模型" 是Martin Fowler提出的一个概念，用来描述那些只有数据没有行为的对象模型。在典型的Spring Boot项目里我们最熟悉的是Controller → Service → Dao。一开始大家都相安无事。但因为业务迭代Service层会变得越来越臃肿，这就是典型的"贫血模型"现象 。

public class OrderService { 
    @Transactional 
    public void updateAddress { 
        Order order = orderMapper.selectById; 
        if .equals || order.getStatus.equals) { 
            order.setAddress; 
            order.setUpdateTime); 
            orderMapper.updateById; 
        } else { 
            throw new BusinessException; 
        } 
    } 
}

原来如此。 "贫血模型"" 的危害在于 ， 它违背了面向对象的基本原则—— "Tell, Don't Ask"" 。 我们的代码应该告诉对象做什么 ， 而不是问它是什么状态后再做决定 。

public class Order { 
    private Integer status; 
    private String address; 
    // ... or fields 
    public void changeAddress { 
        if ) { 
            throw new BusinessException; 
        } 
        this.address = newAddress; 
        this.updateTime = LocalDateTime.now; 
    } 
} 

"并发编程"最佳实践

要我说... JUC" 包提供了非常丰富的并发工具类 ， 比方说 FutureTask , ForkJoinPool , 以及各种 BlockingQueue " 等等 。 这些工具经过多年的锤炼 ， 可以帮助我们解决绝大多数的多线程编程问题 。

 public class OrderService { 
     public void updateAddress { 
         Order order = orderRepository.findById; 
         // Service变得极度清爽，只负责协调
         order.changeAddress; 
         orderRepository.save; 
     } 
 }