C++

1、《高性能 Windows Socket 服务端与客户端组件（源代码及测试用例下载）》

    《基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件的设计与实现》

    《通用异步 Windows Socket TCP 客户端组件的设计与实现》

　　摘要：编写 Windows Socket TCP 客户端其实并不困难，Windows 提供了6种 I/O 通信模型供大家选择。但本座看过很多客户端程序都把 Socket 通信和业务逻辑混在一起，剪不断理还乱。每个程序都 Copy / Parse 类似的代码再进行修改，实在有点情何以堪。因此本座利用一些闲暇时光写了一个基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件和一个通用异步 Windows Socket TCP 客户端组件供各位看官参详参详，希望能激发下大家的灵感。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip

2、《Windows C++ 应用程序通用日志组件（组件及测试程序下载）》

　　摘要：编写一个通用的日志组件应该着重考虑三个方面：功能、可用性和性能。下面，本座详细说明在设计日志组件时对这些方面问题的考虑：

• • 功能：本日志组件的目的是满足大多数应用程序记录日志的需求 —— 把日志输出到文件或发送到应用程序中，并不提供一些复杂但不常用的功能
  • 可用性：本日志组件着重考虑了可用性，尽量让使用者用起来觉得简便、舒心
  • 性能：性能是组件是否值得使用的硬指标，本组件从设计到编码的过程都尽量考虑到性能优化

　　资源下载地址：http://ldcsaa.googlecode.com/files/VC_Logger.zip

3、《如何养成良好的 C++ 编程习惯（一）—— 内存管理》

　　摘要：说起 C/C++ 的内存管理似乎令人望而生畏，满屏的 new / delete / malloc / free，OutPut 窗口无尽的 Memory Leak 警告，程序诡异的 0X00000004 指针异常，仿佛回到那一年我们一起哭过的日子，你 Hold 得住吗？其实，现实并没有你想的那么糟糕。只要你付出一点点，花一点点心思，没错！就一点点而已 —— 用 C++ 类封装内存访问，就会解决你大部分的烦恼，让你受益终身。以 Windows 程序为例，主要有以下几种内存管理方式：

• • 虚拟内存（Virtual Memory）
  • 默认堆和私有堆（Process Heap & Private Heap）
  • 内存映射文件（File Mapping）
  • 进程堆栈（Heap，其实就是用 malloc() 或 默认的 new 操作符在 Process Heap 里一小块一小块地割肉 ^_^）
  • 栈（Stack，内存由调用者或被调用者自动管理）

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src 目录中）

4、《实现 Win32 程序的消息映射宏（类似 MFC ）》

　　摘要：对于消息映射宏，不用多说了，用过 MFC 的人都很清楚。但目前有不少程序由于各种原因并没有使用 MFC，所以本帖讨论一下如何在 Win32 程序中实现类似MFC的消息映射宏。其实 Windows 的头文件 “WindowsX.h”（注意：不是“Windows.h”） 中提供了一些有用的宏来帮助我们实现消息映射。本座是也基于这个头文件实现消息映射。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/Win32Helper.h 文件中）

5、《用宏实现 C++ Singleton 模式》

　　摘要：Singleton 设计模式应用非常广泛，实现起来也很简单，无非是私有化若干个构造函数，“operator =” 操作符，以及提供一个静态的创建和销毁方法。但是对每个类都写这些雷同的代码是本座不能容忍的，因此，本座使用宏把整个 Singleton 模式封装起来，无论是类的定义还是类的使用的极其简单。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/Singleton.h 文件中）

6、《C++ 封装私有堆（Private Heap）》

　　摘要：Private Heap 是 Windows 提供的一种内存内存机制，对于那些需要频繁分配和释放动态内存的应用程序来说，Private Heap 是提高应用程序性能的一大法宝，使用它能降低 new / malloc 的调用排队竞争以及内存空洞。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/PrivateHeap.h 文件中）

7、《基于 crt debug 实现的 Windows 程序内存泄漏检测工具》

　　摘要：Windows 程序内存泄漏检测是一项十分重要的工作，基于 GUI 的应用程序通常在调试结束时也有内存泄漏报告，但这个报告的信息不全面，不能定位到产生泄漏的具体行号。其实自己实现一个内存泄漏检测工具是一件非常简单的事情，但看过网上写的很多例子，普遍存在两种问题：

• • 要么考虑不周全，一种环境下能用，而在另外一种环境下却不能很好工作，或者漏洞报告的输出方式不合理。
  • 要么过于保守，例如：完全没有必要在 _malloc_dbg() 和 _free_dbg() 的调用前后用 CriticalSection 进行保护（跟踪一下多线程环境下 new 和 malloc 的代码就会明白）。

　　资源下载地址：http://ldcsaa.googlecode.com/files/socket_server_and_client.zip （源代码在 Common/Src/debug/win32_crtdbg.h 文件中）

Java

1、《Portal-Basic Java Web 应用开发框架 v2.6.2 发布（源码、示例及文档）》

　　摘要：Portal-Basic Web 应用开发框架（简称 Portal-Basic）是一套功能完备的高性能 Web 应用开发框架，内置可扩展的 MVC Web 基础架构和 DAO 访问接口（已内置 Hibernate、MyBatis 和 JDBC 支持），集成 Action拦截、Form Bean / Dao Bean / Spring Bean 装配、国际化、文件上传下载和缓存等基础 Web 应用组件，提供高效灵活的纯 Jsp/Servlet API 编程模型，完美整合 Spring，非常容易学习和使用。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list

2、《用 Java 实现的日志切割清理工具（源代码下载）》

　　摘要：对于服务器的日常维护来说，日志清理是非常重要的事情，如果残留日志过多则严重浪费磁盘空间同时影响服务的性能。如果用手工方式进行清理，会花费太多时间，并且很多时候难以满足实际要求。例如：如何在每个星期六凌晨3点把超过2G大的日志文件进行切割，保留最新的100M日志记录？网上没有发现能满足本座要求的日志切割工具，因此花了一些闲暇时间自己写了一个。由于要在多个平台上使用，为了方便采用 Java 实现。本工具命名为 LogCutter，主要有以下特点：

• • 支持 Linux、Mac 和 Windows 等所有常见操作系统平台
  • 支持命令行交互式运行
  • 支持后台非交互式运行（Linux/MAC 下使用 daemon 进程实现，Windows 用系统 Service 实现）
  • 支持两种日志清理方式（删除日志文件或切割日志文件）
  • 支持对 GB18030、UTF-8、UTF-16LE、UTF-16BE 等常用日志文件类型进行切割（不会发生切掉半个字符的情况）
  • 高度可配置（程序执行周期、要删除的日志文件过期时间、要切割的日志文件阀值和保留大小等均可配置

　　资源下载地址：http://ldcsaa.googlecode.com/files/LogCutter.zip

3、《通用 Java 文件上传和下载组件的设计与实现》

　　摘要：文件上传和下载是 Web 应用中的一个常见功能，相信各位或多或少都曾写过这方面相关的代码。但本座看过不少人在实现上传或下载功能时总是不知不觉间与程序的业务逻辑纠缠在一起，因此，当其他地方要用到这些功能时则无可避免地 Copy / Pase，然后再进行修改。这样丑陋不堪的做法导致非常容易出错不说，更大的问题是严重浪费时间不断做重复类似的工作，这是本座绝不能容忍的。哎，人生苦短啊，浪费时间在这些重复工作身上实在是不值得，何不把这些时间省出来打几盘罗马或者踢一场球？为此，本座利用一些闲暇之时光编写了一个通用的文件上传和文件下载组件，实现方法纯粹是基于 JSP，没有太高的技术难度，总之老少咸宜 ^_^。现把设计的思路和实现的方法向各位娓娓道来，希望能起到抛砖引玉的效果，激发大家的创造性思维。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list （作为 Portal-Basic 第一部分，代码在 com.bruce.util.http 包中）

4、《深度剖析：Java POJO Bean 对象与 Web Form 表单的自动装配》

　　摘要：时下很多 Web 框架 都实现了 Form 表单域与 Java 对象属性的自动装配功能，该功能确实非常有用，试想如果没这功能则势必到处冲积着 request.getParameter() 系列方法与类型转换方法的调用。重复代码量大，容易出错，同时又不美观，影响市容。现在的问题是，这些框架通过什么方法实现自动装配的？如果不用这些框架我们自己如何去实现呢？尤其对于那些纯 JSP/Servlet 应用，要是拥有自动装配功能该多好啊！本座深知各位之期盼，决定把自动装配的原理和实现方法娓娓道来。

　　资源下载地址：http://code.google.com/p/portal-basic/downloads/list （作为 Portal-Basic 第一部分，代码在 com.bruce.util 包中）

5、《Linux 安装 MySQL / MySQL 主从备份》

　　资源下载地址：http://ldcsaa.googlecode.com/files/services.zip

 原文出处：怪兽的博客  怪兽的微博  怪兽乐园Q群

　　（轻踩这里，你懂的 ^_*）

原文：《基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件的设计与实现》

设计概述

　　服务端通信组件的设计是一项非常严谨的工作，其中性能、伸缩性和稳定性是必须考虑的硬性质量指标，若要把组件设计为通用组件提供给多种已知或未知的上层应用使用，则设计的难度更会大大增加，通用性、可用性和灵活性必须考虑在内。

　　现以一个基于 IOCP 的通用异步 Windows Socket TCP 服务端组件为例子，讲述其设计与实现相关的问题，希望能引发大家的思考，对大家日后开展相关类似工作时有所帮助。关于通用性、可用性、Socket 模型选型以及接口模型的设计等问题已经在本座前段时间发表的《通用异步 Windows Socket TCP 客户端组件的设计与实现》中进行过阐述，此处就不再重复了。现在主要针对服务端通信组件的特点阐述设计其设计和实现相关的问题。

　　一、线程结构

　　与组件相关的线程有 3 种：使用者线程、Accept  线程和工作线程，其中后 2 种由组件实现。

1. 1. 使用者线程：通过调用 Start/Stop/Send 等组件方法操作组件的一个或多个线程，通常是程序的主线程或其它业务逻辑线程。
   2. Accept 线程：使用 AcceptEx() 接收客户端连接请求并创建 Client Socket 的线程，将其独立出来，实现为单独的线程将使组件的模块划分更清晰，更重要的是避免与业务逻辑和通信处理的相互影响。
   3. 工作线程：使用 GetQueuedCompletionStatus() 监听网络事件并处理网络交互的多个线程，工作线程处理完网络事件后会向上层应用发送 OnAccept/OnSend/OnReceive 等组件通知。工作线程的数量可以根据实际情况之行设置（通常建议为：CPU Core Number * 2 + 2）。

　　注意：如果上层应用在接收到 OnAccept/OnSend/OnReceive 这些组件通知时直接进行业务逻辑处理并在其中操作组件，则工作线程也成为了使用者线程。另外，如果要处理的业务逻辑比较耗时，上层应用应该在接收到组件通知后交由其他线程处理。

　　二、性能

　　组件采用 Windows 平台效率最高的 IOCP Socket 通信模型，因此在通信接口的性能方面是有保证的，这里就不多说了。现在从组件的设计与实现的角度来来阐述性能的优化。组件在代码级别做了很多优化，一些看似多余或繁琐的代码其实都是为了性能服务；组件在设计方面主要采用了 2 中优化策略：缓存池和私有堆。

1. 缓存池：在通信的过程中，通常需要频繁的申请和释放内存缓冲区（TBufferObj）和 Socket 相关的结构体（TSocketObj），这会大大影响组件的性能，因此，组件为 TBufferObj 和 TSocketObj 建立了动态缓存池， 只有当缓存池中没有可用对象时才创建新对象，而当缓存对象过多时则会压缩缓存池。
2. 私有堆（Private Heap）：在操作系统中，new / malloc 等操作是串行化的，虽然一般的应用程序不用太在乎这个问题，但是在一个高并发的服务器中则是个不可忽略的问题，另外 TBufferObj 和 TSocketObj 均为大小固定的结构体，因此非常适合在私有堆中分配内存，避免与 new / malloc 竞争同时又减少内存空洞。（关于私有堆的使用方法请参考这里 ^_^）

　　三、通用性与可用性

　　与《通用异步 Windows Socket TCP 客户端组件的设计与实现》描述的客户端接口一样，服务端组件也提供了两组接口：ISocketServer 接口提供组件操作方法，由上层应用直接调用；IServerSocketListener 接口提供组件通知方法，由上层应用实现，这两个接口设计得非常简单，主要方法均不超过 5 个。由于组件自身功能完备（不需要附带其它库或代码）并且职责单一（只管通信，不参与业务逻辑），因此可以十分方便第整合到任何类型的应用程序中。

　　四、伸缩性

　　可以根据实际的使用环境要求设置工作线程的数量、 TBufferObj 和 TSocketObj 缓存池的大小、TBufferObj 缓冲区的大小、Socket 监听队列的大小、AccepEx 派发的数目以及心跳检查的间隔等。

　　五、连接标识

　　组件完全封装了所有的底层 Socket 通信，上层应用看不到任何通信细节，不必也不能干预任何通信操作。另外，组件在 IServerSocketListener 通知接口的所有方法中都有一个 Connection ID 参数，该参数作为连接标识提供给上层应用识别不同的连接。

原文：《通用异步 Windows Socket TCP 客户端组件的设计与实现》

设计概述

　　编写 Windows Socket TCP 客户端其实并不困难，Windows 提供了6种 I/O 通信模型供大家选择。但本座看过很多客户端程序都把 Socket 通信和业务逻辑混在一起，剪不断理还乱。每个程序都 Copy / Parse 类似的代码再进行修改，实在有点情何以堪。因此本座利用一些闲暇时光写了一个基于 IOCP 的通用异步 Windows Socket TCP 高性能服务端组件和一个通用异步 Windows Socket TCP 客户端组件供各位看官参详参详，希望能激发下大家的灵感。本篇文章讲述客户端组件。闲话少说，我们现在步入正题。

• 最重要的第一个问题：如何才能达到通用？

　　答：很简单。

　　　　1、限制组件的职能，说白了，通信组件的唯一职责就是接受和发送字节流，绝对不能参与上层协议解析等工作。不在其位不谋其政就是这个意思。

　　　　2、与上层使用者解耦、互不依赖，组件与使用者通过接口方法进行交互，组件实现 ISocketClient 接口为上层提供操作方法；使用者通过 IClientSocketListener 接口把自己注册为组件的 Listener，接收组件通知。因此，任何使用者只要实现了 IClientSocketListener 接口都可以使用组件；另一方面，你甚至可以自己重新写一个实现方式完全不同的组件实现给使用者调用，只要该组件遵从 ISocketClient 接口。这也是 DIP 设计原则的体现（若想了解更多关于设计原则的内容请猛击这里 ^_^）。

• 最重要的第二个问题：可用性如何，也就是说使用起来是否是否方便？

　　答：这个问题问得很好，可用性对所有通用组件都是至关重要的，如果太难用还不如自己重头写一个来得方便。因此，ISocketClient 和 IClientSocketListener 接口设计得尽量简单易用（通俗来说就是“傻瓜化”），这两个接口的主要方法均不超过 5 个。

• 最重要的第三个问题：组件的性能如何？

　　作为底层的通用组件，性能问题是必须考虑的，绝对不能成为系统的瓶颈。而另一方面，从实际出发，毕竟只是一个客户端组件，它的并发性要求远没有服务端那么高。因此，组件在设计上充分考虑了性能、现实使用情景、可用性和实现复杂性等因素，确保满足性能要求的同时又不会写得太复杂。做出以下两点设计决策：

1. 在单独线程中实现 Socket 通信交互。这样可以避免与主线程或其他线程相互干扰。
2. I/O 模型选择 WSAEventSelect。细说一下选择这种 I/O 模型的原因：（各种 I/O 模型的性能比较可以参考：《Windows 网络编程（中文第二版）》第 154 页）
   • 阻塞模型：（不解析，你懂的^_^）
   • 非阻塞模型：（性能太低）
   • WSAAsyncSelect： （两个原因：a、性能太低；b、对于纯 Console 程序还要背负 HWND 实在是伤不起呀！）
   • 重叠 I/O：（有点复杂了）
   • 完成端口：（何必呢？）

 原文出处：怪兽的博客  怪兽的微博  怪兽乐园Q群