一、背景

做软件开发同学的从性格上来说有两类人：外向的、内向的。

外向的人在工作中擅长交流，内向的人在工作中善于总结，两种的人都是开发团队需要的。

外向的人在工作中善于活跃团队内的气氛，逐渐走向技术管理路线，带领团队走的更远，控制开发目标与路线；内向的人更擅长观察，容易成为团队的定心骨，逐渐走向技术专家路线，肯研究肯花时间提高自己。

那么，在这个过程中，内向人前期的成长尤为重要，合适的工作方法和习惯也会提高在团队中的地位，而不是单纯的低头干活，本文分享下自己的经验，不一定对希望对大家有参考。

不同的性格的人，具有不同的工作方式和方法，和生活习惯，对于软件开发这个职场环境来说，内向性格不是劣势，很多人外表看着外向，其实潜意识也有很多内向性格的特征。

内向也是人的宝贵的一面，有时也是能力优势的一部分（如善于深度思考等），如果让自己掌握外向同学的行动方式，逐渐的做出改变，会更好。

二、现状

 刚毕业不久进入到职场中工作的毕业生，如果性格是外向的，那么他其实问题并不大，很多的时候，可以快速调整自己，并被其他人看到自己的工作成果，而内向性格的毕业生，如果在职场中没有主动去做某些工作和承担哪些职责，或对自己目前的工作状况没有及时调整和改变，就会造成成长缓慢，有的人会出现明明自己每天努力学习，却还是工作中那个让同时感觉能力最差的，导致经常没有分配到核心的开发工作，长此以往，消极的各种状态就出现了。

比如内向性格的毕业生在初入职场中经常会出现如下症状：

1、明知项目组的工作环境和方式存在一些不健康的因素，自己不太愿意去参与或评论

2、对开发整体流程和环节不清楚，及需求的判断有问题，需求频繁改动，代码写了被删除，自己却不敢说，或说了一次被骂以后沉默了

3、项目组缺失技术经理等全流程人员，需求自己理解和功能设计，自己却没有及时吧自己的想法与他人沟通 ，外包团队更明显

4、身边缺乏可以聊天的mentor、同事，自己感觉开发能力无法提升，却一直憋在心里，产生怀疑

5、不知道工作中如何问同事问题，才愿意帮忙解答，持续很长时间未获得同事的信任

6、有时过于逞强，不想让别人觉得自己不行，不会拒绝，实际工作量与评估有差别，导致自己延误工期。

以上的这些问题，可能不止内向性格的人会有，很多外向的人可能也会有，只是在内向性格的人身上更明显而已，如果内向性格的毕业生，明知道自己有这种情况，却不思考解决办法和改变，长时间后自我开始产生怀疑。 职场中，沟通、反馈、改变是很重要的，但是沟通不一定就是说话，反馈不一定是面对面，而改变是一直要持续去做的。 

之前看过一点得到的沟通训练营的视频教程，感觉里面有些技巧是值得大家去学习的，不仅仅是开发类型的同学。

三、经验分享

 下面我分享下，我的一些经验，可能不太对，但是希望可以帮助到看到这篇文章，深有同感的你。 

问题1：内向性格的毕业生，说的话，或者请求别人的东西，别人听不懂怎么办？

 这里先记住一件事情，在职场中，开发者要学会给不懂技术的人员，讲明白事情，要逐渐学会用生活中的事情去类比。

这个真的很重要，当你给不懂技术人讲的多以后，很多人可能都会来请教你关于某件事的理解，这个通常我们和系统的售前、需求人员、产品人员用的比较多，得学会用生活中的例子或故事去告诉他，XX能做，XX不能做的原因是什么。要坚持去练习。 

 对于请教一些人技术问题时，不管是同事也好还是网友也好，要明确自己给他的这个消息，别人是否会听懂，马上给出解决办法，还是别人看到这个问题以后，还要和我交流1小时才能知道是啥意思，这个也是很多有经验的人，不愿因帮助低级程序员的原因，这里分享下请教问题的描述模板： 

我遇到了一个问题或场景：【问题描述】，我想要实现【X功能】，但是出现了【Y现象】，我经过以下尝试：【思路细节】，但是不能解决，报错如下：【报错信息或截图】，或者我使用【关键词】百度，但是找不到答案，请问我该怎么解决或分析。

 而很多时候有经验的人，也会发现你百度的搜索词不对，这个时候，他根据你的阐述可能会告诉你怎么输入比较靠谱的搜索词来解决办法。 

问题2：评估工作计划有时过于逞强，不想让别人觉得自己不行，不会拒绝

这个真的想说，工作前期真的别逞强，没做过就是没做过，不行就是不行，别找啥接口，但是别直接和负责人说这个东西我不会（这个是很不好的，不能说不会，这是明显不相干的意思），比较合适的说法是：这个东西或概念我暂时不太清楚，没接触过过，需要一会儿或下来后我需要去研究下，然后咱们在沟通或者确定一下。 

 而很多内向性格的毕业生，缺少了这种意识，同时安排某项工作任务时，缺少对任务的分解能力和排期能力和工作后排期后的To do List梳理能力，以至于自己5天完成的任务，口头说2天就搞定了。 

 其实这种，前期mentor该给你做个示范分解的操作，或者自己主动问下，如何分解项目的需求和任务。

 而真正开发的时候，每天可能都感觉这里需要加上XXX功能，那里需要加上YYY功能，但是不知道是否需要做，这里我的建议是，把他加入到自己To do List中，然后找个时间和同事去沟通下这个想法，长此以往，同事的心里，你就是一个有想法的人，虽然不善言辞。

 主要就是这里，我们要体现自己的一个工作的对待方式，而不是一直被动接受，不拒绝，不反馈。 

问题3：明显知道产品经理、项目经理等等人员对需求的认识不足，自己闷着不反馈和说话

 很多时候，任务的返工和需求的变更，有一部分是这个原因的，在经验尚少的情况下，自己未能说出自己对这个需求的认识和怀疑，就去搞了，最后大家都不是特别的好，尤其是在产品需求设计初期，包括需求提出者也是理解不够的，这里可能有很多内容其实是你可以提供的服务，也有一些是产品在犹豫使用哪种方式实现的功能，在与你讨论后，觉得你说的又道理，而决定复用你已经有的系统。 

 很多出入职场的同学，觉得没成长也有这方面的一点原因，自己开发的功能，缺少自己设计思想和认知的影子，如果能在当前系统中体现出了自己的想法，时间久了多少成就感会有点提升的。 

要学会做自己负责的模块/功能的主人，把他们当做自己的孩子一样，主键养成主人翁的意识

问题4：项目组，当前啥都没有，文档、测试，自己也和别人一样不做改变

 这个也是目前很多公司的现状，但是不代表别人不干，你就不干，这个时候，谁主动，谁就能表现一把，同时，这也是被动让同事主动问你或咨询你的机会。

 比如没有协同的东西，那你能不能自己先装个Confluence Wiki或飞书云文档工具，自己先用起来，然后某个时机在同事眼前展示下，自己基于这个软件形成的技术思考、技术经验、技术记录等等等。

比如没有自动发布或代码质量的东西，那你能不能自己先搞个jenkins、sonarqube、checkstyle、findbug，让自己每次写完的代码，自己先搞下，然后某个时机告诉同事这个东西必须这么写怎怎么样。

 是不是有人又说了，工作没时间搞这些东西，你是不是又在扯皮呢，我只能说起码比你空闲时间自己偷偷学习公司短期内用不上的技术或长时间用不上的东西好吧，至少我能非常快速的获得1个同事的信任、2个同事的信任，从而获得团队的信任与核心工作的委派。

大部分人的想用的技术都是和公司的技术栈不搭边的，至少先把脚下的路走出来。

四、总结

 其实最近几年，发现好像很多人被卷字冲昏了头脑，每天都在想着高大尚的技术点和八股文，导致短期的这个工作没干好，还说没成长，以至于某些情况下还被认为是工作和团队中那个能力最差的，即使做了很多的努力。我想说的是，某段时间点或时期内，至少要把当前工作做好在谈论吧，这个在一些内向性格的人身上会表现的明显一些。

IT行业，很多优秀的人也是内向性格的，掌握了合适方法，会让他们成为内向性格顶端的那批优秀的人群。 

说道性格吧，即使是内向型的，可能针对十二星座还是衍生出不同的人生和结果，每个星座的也是有区别的。而在这里面最突出的我觉得是天蝎座的人群。

身为天蝎座的我，经常会想到那些和我一个星座的大佬们：

搜狐创始人张朝阳、腾讯创始人马化腾、百度创始人李彦宏、雅虎创始人杨致远、微软创始人比尔.盖茨、联想集团CEO杨元庆、推特CEO杰克.多尔西、新浪董事长曹国伟。

他们的成长也一直在激励着我。

大家好，我是 shixin。

岁数越大，越不愿承认自己的真实年龄。前段时间别人问我年纪的时候，我嘴硬的说“二十九周岁”，现在，就只能无奈的说“三十”了。

说来也奇怪，为什么会觉得无奈呢？我想，我是想保留「二十多岁」的青春朝气、心无旁骛，抗拒「三十多岁」的中年危机、生活压力。

无论怎样我终究还是和三十岁相遇了，既然逃不掉，那今天就和它聊一聊。

三十岁意味着什么

我拿着这个问题问了 ChatGPT，它根据我的上下文给的回答如下：

可以看到，它给的回答还是蛮好的，基本上道出了现在困扰我的一些点。

三十岁，工作和生活对我的要求更高了。

工作方面，现在需要考虑的比以前更多了一些。除了个人贡献还需要做团队贡献，为自己的小组和整个团队带来更大价值，把自己知道的技术和经验传播给更多小伙伴。

家庭方面，快到要小孩的时候了。理论上三十岁已经年纪不小应该响应国家号召，但无奈生娃养娃的成本太大，还得多奋斗几年才有底气。今年准备先把婚礼办了（疫情影响婚礼日期改了好几次，上帝保佑这次顺利），过两年再考虑要孩子吧。

至于工作生活的平衡，老实讲目前还没有足够的资本，还得在工作上投入大部分时间。如何解决这种情况呢？是个值得思考的问题。

三十岁前我的人生

三十岁前，我的人生里有很多意想不到。

十岁的我，没有想到未来我会去包头，更没有想到会在高中遇到现在的老婆。那时的我在呼和浩特，有四五个很要好的朋友，搬家的时候心里有一万个不舍。

十五岁的我，没有想到我会去西安读书，学的是计算机。那时的我还在想方设法溜到网吧通宵打游戏。

二十岁的我，没有想到我会从事安卓开发，也没有想到会去上海工作。那时的我在盲目瞎学，手机上写 OJ，看小甲鱼和黑马程序员，图书馆借了几本很老的 MFC 和 HTML CSS 书，跟着例子敲出来一个 H5 打飞机游戏。

二十五岁的我，没有想到我会在上海定居。那时我想的是干几年去西安定居，在那里离老家近一点，买房压力也小一点。后来机缘巧合，在买房时和几个前辈朋友聊了聊，听了他们的劝导，改成在上海定居。

ChatGPT 的这段回答让我泪目。有时候打的字越多，越渴望得到认可的回复，这种感觉，它给到了。

三十岁的我，虽然没有 100% 达到五年前预想的目标，但好在完成了一些当时觉得很难的事，比如买房、写书、直播分享，这些事是我成长的见证，也让我沉淀下一些经验和教训。

希望自己可以继续保持的

我希望自己继续保持的第一个点：在损失可以接受的情况下，多尝试多探索。

之前打德扑的时候，我属于比较激进和浪的那种，这种性格的缺点是会浪费很多筹码，但优点是过程很有趣，也常常会博到一些额外的收益。

生活里也是类似，在大学做小生意的时候，我愿意多跑几家店看看有没有价格更合适的货，也愿意多推开一扇门去问一下是否有需求，虽然收到不少白眼、也没赚大钱，但这段经历让我意识到：反正被拒绝也没什么损失，多试一次就多一个机会。

第二个需要继续保持的点：多种善因。

过往人生的关键节点，让我深刻的感受到：当下的果，往往来自过去不经意间种下的因。

就拿今年的几件事来说：

1. 二月有机会在社区里做分享，缘自去年国庆主动报名 GDE 项目，虽然没通过筛选，但好在建立了联系，有这种机会时人家才会想到我

2. 上周组里做的 ReactNative 技术培训，缘自字节时做的 Diggo 项目，在其中提升了前端开发技术，以至于后面做 RN 很顺畅，从而走在团队前头

今年很多事都是之前种下的善因结出的果实，除了满足，还需要多想想：

1. 怎样为以后种下更多善因

2. 现在要做的事，从长期来看，重复多次后的收益是怎样的

第三个需要继续保持的点：每日、每周、每年必做计划。

每日预则立，不立则废。我是一个善忘的人，如果哪天没有定好计划，基本上就稀里糊涂的过去了。首次发现这个问题，是我写2016 年度总结的时候，回顾发现好多细节都不记得了，有的月份里可能只记得一两件事，剩下的日子都进了黑洞无影无踪。

从那以后我就经常做记录、做计划，既然内存不够用，那就用磁盘缓存。做好每天的计划后，即使被突发事情分了心，我也可以及时调整状态回归高优。在日积月累下，才渐渐地完成了一件件看似很难的事，比如一篇有价值的文章、一个高质量的开源库（github.com/shixinzhang…）。

希望自己可以避免的

除了需要继续保持的，我也有很多后悔的事，比如做错事、说错话、浪费时间。

总结原因后，大概有这几点需要避免：

1. 避免思想上的懒惰，少说这样的话：没办法、算了、就这样吧；多说：我试试、或许这样做就可以

2. 避免和他人比较，比别人优秀或者差都不重要，重要的是有没有持续前进

3. 避免没有进展的时候硬逼自己，多思考方向、方法是不是有问题

4. 避免花钱的时候只看价钱，不对比购买后的体验和长期区别

5. 避免做计划的时候过于悲观，目标定高点才可能做的更好

6. 避免追求完美而不愿意开始，做完比做好优先级更高

7. 避免在累的时候不休息，贪图享乐而继续浑浑噩噩

8. 
   

   避免骄傲自满、自我膨胀，骄傲一来羞耻就来了

   
   

大胆想象一下，三十五岁的我

借用亚马逊的逆向工作法，先想象一下我 35 岁的情况：

1. 第一种可能：独立开发了某个产品，为细分领域的人提供了独特的价值，从而获得不错的收益，业务比较忙的时候雇佣了几个助手

2. 第二种可能：继续打工，但因为技术较好、沟通表达能力不错、有商业思维，担任某个业务的技术负责人

3. 第三种可能：因为工作经验和年纪薪资不匹配被裁，投简历基本没有回复，最后忍痛降薪 50% 接了个 offer

要达到第一种情况，需要具备技术广度，可以独立完成产品的需求调研、设计、全栈开发和运营，更重要的是，尽早捕捉到信息，挖掘出其中的信息不平衡点或者需求点。这种情况对人的要求更高、风险也更高。

要达到第二种情况，需要付出的努力比上面略微少一点，需要具备一定的技术深度和广度、提升对公司业务和行业趋势的了解，主导完成一些有价值的事，同时在公司内部有一定的影响力。这种情况比第一种更稳一点。

要避免第三种情况，需要经常了解市场相关岗位的要求，不断提升自己的技术和业务价值以匹配要求，最好有代表性的作品和影响力。

总结

这篇文章是我三十岁当天开始动笔写的，因为种种原因拖到今天才完成，实在不应该（捂脸哭。

总是听人讲“三十而立”，为了看自己到底立没立，我看了好些名人的视频，想从中寻找答案。

到现在我悟了，所谓的“立“就是建立、确定、稳固。人活着最重要的就是吃饱和开心，三十岁，能够有一技之长和自我融洽的三观，就算是立住了吧！

这篇文章是基于课程 Go 开发短地址服务 做的笔记

项目地址：github.com/astak16/sho…

错误处理

在处理业务逻辑时，如果出错误了，需要统一处理错误响应的格式，这样可以方便前端处理错误信息

所以需要定义一个 Error 接口，它包含了 error 接口，以及一个 Status() 方法，用来返回错误的状态码

type Error interface {

  error

  Status() int

}

这个接口用来判断错误类型，在 go 中可以通过 e.(type) 判断错误的类型

func respondWithError(w http.RespondWrite, err error) {

  switch e.(type) {

  case Error:

    respondWithJSON(w, e.Status(), e.Error())

  default:

    respondWithJSON(w, http.StatusInternalServerError, http.StatusText(http.StatusInternalServerError))

  }

}

在 go 中 实现 Error 接口，只需要实现 Error() 和 Status() 方法即可

func () Error() string {

  return ""

}

func () Status() int {

  return 0

}

这样定义的方法，只能返回固定的文本和状态码，如果想要返回动态内容，可以定义一个结构体

然后 Error 和 Status 方法接受 StatusError 类型

这样只要满足 StatusError 类型的结构体，就可以返回动态内容

所以上面的代码可以修改为：

type StatusError struct {

  Code int

  Err error

}

func (se StatusError) Error() string {

  return se.Err.Error()

}

func (se StatusError) Status() int {

  return se.Code

}

middlerware

RecoverHandler

中间件 RecoverHandler 作用是通过 defer 来捕获 panic，然后返回 500 状态码

func RecoverHandler(next http.Handler) http.Handler {

  fn := func(w http.ResponseWriter, r *http.Request) {

    defer func() {

      if r := recover(); r != nil {

        log.Println("Recover from panic %+v", r)

        http.Error(w, http.StatusText(500), 500)

      }

    }()

    next.ServeHTTP(w, r)

  }

  return http.HandlerFunc(fn)

}

LoggingHandler

LoggingHandler 作用是记录请求耗时

func (m Middleware) LoggingHandler(next http.Handler) http.Handler {

  fn := func(w http.ResponseWriter, r *http.Request) {

    start := time.Now()

    next.ServeHTTP(w, r)

    end := time.Now()

    log.Printf("[%s] %q %v", r.Method, r.URL.Path, end.Sub(start))

  }

  return http.HandlerFunc(fn)

}

中间件使用

alice 是 go 中的一个中间件库，可以通过 alice.New() 来添加中间件，具体使用如下：

m := alice.New(middleware.LoggingHandler, middleware.RecoverHandler)

mux.Router.HandleFunc("/api/v1/user", m.ThenFunc(controller)).Methods("POST")

生成短链接

redis 连接

func NewRedisCli(addr string, passwd string, db int) *RedisCli {

  c := redis.NewClient(&redis.Options{

    Addr:     addr,

    Password: passwd,

    DB:       db,

  })



  if _, err := c.Ping().Result(); err != nil {

    panic(err)

  }

  return &RedisCli{Cli: c}

}

生成唯一 ID

redis 可以基于一个键名生成一个唯一的自增 ID，这个键名可以是任意的，这个方法是 Incr

代码如下：

err = r.Cli.Incr(URLIDKEY).Err()

if err != nil {

  return "", err

}



id, err := r.Cli.Get(URLIDKEY).Int64()

if err != nil {

  return "", err

}



fmt.Println(id) // 每次调用都会自增

存储和解析短链接

一个 ID 对应一个 url，也就是说当外面传入 id 时需要返回对应的 url

func Shorten() {

  err := r.Cli.Set(fmt.Sprintf(ShortlinkKey, eid), url, time.Minute*time.Duration(exp)).Err()

  if err != nil {

    return "", err

  }

}

func UnShorten() {

  url, err := r.Cli.Get(fmt.Sprintf(ShortlinkKey, eid)).Result()

}

redis 注意事项

redis 返回的 error 有两种情况：

1. redis.Nil 表示没有找到对应的值


2. 其他错误，表示 redis 服务出错了

所以在使用 redis 时，需要判断返回的错误类型

if err == redis.Nil {

  // 没有找到对应的值

} else if err != nil {

  // redis 服务出错了

} else {

  // 正确响应

}

测试

在测试用例中，如何发起一个请求，然后获取响应的数据呢？

1. 构造请求

var jsonStr = []byte(`{"url":"https://www.baidu.com","expiration_in_minutes":60}`)

req, err := http.NewRequest("POST", "/api/shorten", bytes.NewBuffer(jsonStr))

if err != nil {

  t.Fatal(err)

}

req.Header.Set("Content-Type", "application/json")

2. 捕获 http 响应

rw := httptest.NewRecorder()

3. 模拟请求被处理

app.Router.ServeHTTP(rw, req)

4. 解析响应

if rw.Code != http.ok {

  t.Fatalf("Excepted status created, got %d", rw.Code)

}



resp := struct {

  Shortlink string `json:"shortlink"`

}{}

if err := json.NewDecoder(rw.Body).Decode(&resp); err != nil {

  t.Fatalf("should decode the response", err)

}

最终完整代码：

var jsonStr = []byte(`{"url":"https://www.baidu.com","expiration_in_minutes":60}`)

req, err := http.NewRequest("POST", "/api/shorten", bytes.NewBuffer(jsonStr))

if err != nil {

  t.Fatal(err)

}

req.Header.Set("Content-Type", "application/json")



rw := httptest.NewRecorder()

app.Router.ServeHTTP(rw, req)



if rw.Code != http.ok {

  t.Fatalf("Excepted status created, got %d", rw.Code)

}

resp := struct {

  Shortlink string `json:"shortlink"`

}{}



if err := json.NewDecoder(rw.Body).Decode(&resp); err != nil {

  t.Fatalf("should decode the response")

}

代码

log.SetFlags(log.LstdFlags | log.Lshortfile)

作用是设置日志输出的标志

它们都是标志常量，用竖线 | 连接，这是位操作符，将他们合并为一个整数值，作为 log.SetFlags() 的参数

• log.LstdFlags 是标准时间格式：2022-01-23 01:23:23


• log.Lshortfile 是文件名和行号：main.go:23

当我们使用 log.Println 输出日志时，会自动带上时间、文件名、行号信息

recover 函数使用

recover 函数类似于其他语言的 try...catch，用来捕获 panic，做一些处理

使用方法：

func MyFunc() {

  defer func() {

    if r := recover(); r != nil {

      // 处理 panic 情况

    }

  }

}

需要注意的是：

1. recover 函数只能在 defer 中使用，如果在 defer 之外使用，会直接返回 nil


2. recover 函数只有在 panic 之后调用才会生效，如果在 panic 之前调用，也会直接返回 nil


3. recover 函数只能捕获当前 goroutine 的 panic，不能捕获其他 goroutine 的 panic

next.ServerHttp(w, r)

next.ServeHTTP(w, r)，用于将 http 请求传递给下一个 handler

HandleFunc 和 Handle 区别

HandleFunc 接受一个普通类型的函数：

func myHandle(w http.ResponseWriter, r *http.Request) {}

http.HandleFunc("xxxx", myHandle)

Handle 接收一个实现 Handler 接口的函数：

func myHandler(w http.ResponseWriter, r *http.Request) {}

http.Handle("xxxx", http.HandlerFunc(myHandler))

他们的区别是：使用 Handle 需要自己进行包装，使用 HandleFunc 不需要

defer res.Body.Close()

为什么没有 res.Header.Close() 方法？

因为 header 不是资源，而 body 是资源，在 go 中，一般操作资源后，要及时关闭资源，所以 go 为 body 提供了 Close() 方法

res.Body 是 io.ReadCloser 类型的接口，表示可以读取响应数据并关闭响应体的对象

w.Write()

代码在执行了 w.Writer(res) 后，还会继续往下执行，除非有显示的 reture 和 panic 终止函数执行

func controller(w http.ResponseWriter, r *http.Request) {

  if res, err := xxx; err != nil {

    respondWithJSON(w, http.StatusOK, err)

  }

  // 这里如果有代码，会继续执行

}

func respondWithJSON(w http.ResponseWriter, code int, payload interface{}) {

  res, _ json.Marshal(payload)

  w.Header().Set("Content-Type", "application/json")

  w.WriteHeader(code)

  w.Write(res)

}

需要注意的是，尽管执行了 w.Writer() 后，还会继续往下执行，但不会再对响应进行修改或写入任何内容了，因为 w.Write() 已经将响应写入到 http.ResponseWriter 中了

获取请求参数

路由 /api/info?shortlink=2

a.Router.Handle("/api/info", m.ThenFunc(a.getShortlinkInfo)).Methods("GET")



func getShortlinkInfo(w http.ResponseWriter, r *http.Request) {

  vals := r.URL.Query()

  s := vals.Get("shortlink")



  fmt.Println(s) // 2

}

路由 /2

a.Router.Handle("/{shortlink:[a-zA-Z0-9]{1,11}}", m.ThenFunc(a.redirect)).Methods("GET")



func redirect(w http.ResponseWriter, r *http.Request) {

  vars := mux.Vars(r)

  shortlink := vars["shortlink"]



  fmt.Println(shortlink) // 2

}

获取请求体

json.NewDecoder(r.Body) 作用是将 http 请求的 body 内容解析为 json 格式

r.body 是一个 io.Reader 类型，它代表请求的原始数据

如果关联成功可以用 Decode() 方法来解析 json 数据

type User struct {

  Name string `json:"name"`

  Age int `json:"age"`

}



func controller(w http.ResponseWriter, r *http.Request){

  var user User

  if err := json.NewDecoder(r.Body).Decode(&user); err != nil {

    fmt.Println(err)

  }

  fmt.Println(user)

}

new

用于创建一个新的零值对象，并返回该对象的指针

它接受一个类型作为参数，并返回一个指向该类型的指针

适用于任何可分配的类型，如基本类型、结构体、数组、切片、映射和接口等

// 创建一个新的 int 类型的零值对象，并返回指向它的指针

ptr := new(int)  // 0

需要注意的是：new 只分配了内存，并初始化为零值，并不会对对象进行任何进一步的初始化。如果需要对对象进行自定义的初始化操作，可以使用结构体字面量或构造函数等方式

往期文章

1. Go 项目ORM、测试、api文档搭建


2. Go 实现统一加载资源的入口<
   
   作者：uccs
   来源：juejin.cn/post/7237702874880393274
   /a>

前言

大家好，我是 simple ，我的理想是利用科技手段来解决生活中遇到的各种问题。

performant npm ，意味高性能的 npm。pnpm由 npm/yarn 衍生而来，解决了 npm/yarn 内部潜在的bug，极大的优化了性能，扩展了使用场景。被誉为"最先进的包管理工具"。

npm,yarn,pnpm的安装区别

首先我创建了三个文件夹分别是npm，yarn和pnpm用于比较三者之间的区别。首先初始化项目，然后安装了express来观察三个文件夹的区别。

npm和yarn的node_modules都是点开之后一眼看不到尽头。

pnpm的node_modules略有区别。

npm/yarn 包结构分析

出现这种情况，是因为yarn和npm安装依赖包，会在node_modules下都平铺出来。现在安装了express，但express中也会有很多不同的依赖。在这些依赖里面有可能又引用了新的依赖，导致node_modules一点开就一望无际了。

初心是好的，因为平铺就可以复用很多依赖。如果说我package A和package B都用了lodash@3.0.0这个包，那么使用平铺，我只需要下载一次lodash即可，节约了装包时间和存储空间。

但是真实开发情况往往是现在下载了五个依赖，其中A,B依赖引用了lodash@3.0.0，而C,D,E引用了lodash@4.0.0。咋整？

npm和yarn目前给出的方案是将其中一个版本，(假设是)lodash@3.0.0的版本放在根目录的node_modules下面，而将需要lodash@4.0.0版本安装到C,D,E的node_modules下。如下所示，A, B可以直接使用lodash@3.0.0，而4,5,6想要使用就只能独自安装lodash@4.0.0。

├─── lodash@3.0.0

├─── package-A

├─── package-B

├─── package-C

│     └── lodash@4.0.0

├─── package-D

│     └── lodash@4.0.0

├─── package-E

│     └── lodash@4.0.0

pnpm包结构分析

按照上文的例子，如果pnpm也安装五个包，A,B依赖引用了lodash@3.0.0，而C,D,E引用了lodash@4.0.0。

├─ .pnpm

│     └── lodash@3.0.0

│     └── lodash@4.0.0

│     └── package-A@1.0.0

│     └── package-B@1.0.0

│     └── package-C@1.0.0

│     └── package-D@1.0.0

│     └── package-E@1.0.0

├──── package-A 符号链接

├──── package-B 符号链接

├──── package-C 符号链接

├──── package-D 符号链接

├──── package-E 符号链接

在pnpm文件夹的node_modules下除了.pnpm文件夹外，就剩下一个package A,B,C,D,E，并且这五个包都是符号链接，它们真正的地址都是在.pnpm下。

也就是说，pnpm通过.pnpm/<name>@<version>/node_modules/<name>找到不同的包，这不仅解决了包重复下载的问题，还顺手解决了幽灵依赖的问题。

幽灵依赖：即开发者并未在package.json中下载相关包，但是在开发过程中却可以直接引用的问题。就是因为npm将依赖直接在node_modules下直接展开，导致开发者可以直接引用。问题就是当开发者升级一些包的时候，那些幽灵依赖可能并不存在于新的版本中，导致项目崩溃。

.pnpm store

pnpm牛皮的地方不只是借用了符号链接解决了包引用的问题，更是借助了硬链接解决了整个直接所有的项目依赖都给整合了，一个包全局只保存一份，并且是通过链接，速度比复制还要快的多。

借一张pnpm官网的图。

从图可以看出，.pnpm store就是依赖的实际存储位置，Mac/linux在{home dir}>/.pnpm-store/v3，windows在当前盘/.pnpm-store/v3。这样就会有个好处，你在多个项目使用的是同一个依赖时，一个包全局只保存一份，这也太省空间了吧。（只要你下载过一次，如果你没有清理.pnpm store，第二次就算你不联网照样能帮你install。）

pnpm store清理

但是，随着使用时间越长，pnpm store也会越来越大。并且随着项目版本的迭代，可能很多包都不再需要了pnpm store依旧会保留着它。此时我们需要定时清理一下。

未引用的包是系统上的任何项目中都未使用的包。 在大多数安装操作之后，包有可能会变为未引用状态，例如当依赖项变得多余时。

最好的做法是 pnpm store prune 来清理存储，但不要太频繁。 有时，未引用的包会再次被需要。 这可能在切换分支和安装旧的依赖项时发生，在这种情况下，pnpm 需要重新下载所有删除的包，会暂时减慢安装过程。

请注意，当 存储服务器正在运行时，这个命令是禁止使用的。

pnpm store prune

原型模式与享元模式

原型模式和享元模式，前者是在创建多个实例时，对创建过程的性能进行调优；后者是用减少创建实例的方式，来调优系统性能。这么看，你会不会觉得两个模式有点相互矛盾呢？

其实不然，它们的使用是分场景的。在有些场景下，我们需要重复创建多个实例，例如在循环体中赋值一个对象，此时我们就可以采用原型模式来优化对象的创建过程；而在有些场景下，我们则可以避免重复创建多个实例，在内存中共享对象就好了。

今天我们就来看看这两种模式的适用场景，看看如何使用它们来提升系统性能。

原型模式

原型模式是通过给出一个原型对象来指明所创建的对象的类型，然后使用自身实现的克隆接口来复制这个原型对象，该模式就是用这种方式来创建出更多同类型的对象。

使用这种方式创建新的对象的话，就无需再通过new实例化来创建对象了。这是因为Object类的clone方法是一个本地方法，它可以直接操作内存中的二进制流，所以性能相对new实例化来说，更佳。

实现原型模式

我们现在通过一个简单的例子来实现一个原型模式：

   //实现Cloneable 接口的原型抽象类Prototype

   class Prototype implements Cloneable {

        //重写clone方法

        public Prototype clone(){

            Prototype prototype = null;

            try{

                prototype = (Prototype)super.clone();

            }catch(CloneNotSupportedException e){

                e.printStackTrace();

            }

            return prototype;

        }

    }

    //实现原型类

    class ConcretePrototype extends Prototype{

        public void show(){

            System.out.println("原型模式实现类");

        }

    }



    public class Client {

        public static void main(String[] args){

            ConcretePrototype cp = new ConcretePrototype();

            for(int i=0; i< 10; i++){

                ConcretePrototype clonecp = (ConcretePrototype)cp.clone();

                clonecp.show();

            }

        }

    }

要实现一个原型类，需要具备三个条件：

• 实现Cloneable接口：Cloneable接口与序列化接口的作用类似，它只是告诉虚拟机可以安全地在实现了这个接口的类上使用clone方法。在JVM中，只有实现了Cloneable接口的类才可以被拷贝，否则会抛出CloneNotSupportedException异常。


• 重写Object类中的clone方法：在Java中，所有类的父类都是Object类，而Object类中有一个clone方法，作用是返回对象的一个拷贝。


• 在重写的clone方法中调用super.clone()：默认情况下，类不具备复制对象的能力，需要调用super.clone()来实现。

从上面我们可以看出，原型模式的主要特征就是使用clone方法复制一个对象。通常，有些人会误以为 Object a=new Object();Object b=a; 这种形式就是一种对象复制的过程，然而这种复制只是对象引用的复制，也就是a和b对象指向了同一个内存地址，如果b修改了，a的值也就跟着被修改了。

我们可以通过一个简单的例子来看看普通的对象复制问题：

class Student {

    private String name;



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name= name;

    }



}

public class Test {



    public static void main(String args[]) {

        Student stu1 = new Student();

        stu1.setName("test1");



        Student stu2 = stu1;

        stu2.setName("test2");



        System.out.println("学生1:" + stu1.getName());

        System.out.println("学生2:" + stu2.getName());

    }

}

如果是复制对象，此时打印的日志应该为：

学生1:test1

学生2:test2

然而，实际上是：

学生1:test2

学生2:test2

通过clone方法复制的对象才是真正的对象复制，clone方法赋值的对象完全是一个独立的对象。刚刚讲过了，Object类的clone方法是一个本地方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。我们可以用 clone 方法再实现一遍以上例子。

//学生类实现Cloneable接口

class Student implements Cloneable{

    private String name;  //姓名



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name= name;

    }

   //重写clone方法

   public Student clone() {

        Student student = null;

        try {

            student = (Student) super.clone();

            } catch (CloneNotSupportedException e) {

            e.printStackTrace();

            }

            return student;

   }



}

public class Test {



    public static void main(String args[]) {

        Student stu1 = new Student();  //创建学生1

        stu1.setName("test1");



        Student stu2 = stu1.clone();  //通过克隆创建学生2

        stu2.setName("test2");



        System.out.println("学生1:" + stu1.getName());

        System.out.println("学生2:" + stu2.getName());

    }

}

运行结果：

学生1:test1

学生2:test2

深拷贝和浅拷贝

在调用super.clone()方法之后，首先会检查当前对象所属的类是否支持clone，也就是看该类是否实现了Cloneable接口。

如果支持，则创建当前对象所属类的一个新对象，并对该对象进行初始化，使得新对象的成员变量的值与当前对象的成员变量的值一模一样，但对于其它对象的引用以及List等类型的成员属性，则只能复制这些对象的引用了。所以简单调用super.clone()这种克隆对象方式，就是一种浅拷贝。

所以，当我们在使用clone()方法实现对象的克隆时，就需要注意浅拷贝带来的问题。我们再通过一个例子来看看浅拷贝。

//定义学生类

class Student implements Cloneable{

    private String name; //学生姓名

    private Teacher teacher; //定义老师类



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    public Teacher getTeacher() {

        return teacher;

    }



    public void setTeacher(Teacher teacher) {

        this.teacher = teacher;

    }

   //重写克隆方法

   public Student clone() {

        Student student = null;

        try {

            student = (Student) super.clone();

            } catch (CloneNotSupportedException e) {

            e.printStackTrace();

            }

            return student;

   }



}



//定义老师类

class Teacher implements Cloneable{

    private String name;  //老师姓名



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name= name;

    }



   //重写克隆方法，对老师类进行克隆

   public Teacher clone() {

        Teacher teacher= null;

        try {

            teacher= (Teacher) super.clone();

            } catch (CloneNotSupportedException e) {

            e.printStackTrace();

            }

            return student;

   }



}

public class Test {



    public static void main(String args[]) {

        Teacher teacher = new Teacher (); //定义老师1

        teacher.setName("刘老师");

        Student stu1 = new Student();  //定义学生1

        stu1.setName("test1");

        stu1.setTeacher(teacher);



        Student stu2 = stu1.clone(); //定义学生2

        stu2.setName("test2");

        stu2.getTeacher().setName("王老师");//修改老师

        System.out.println("学生" + stu1.getName + "的老师是:" + stu1.getTeacher().getName);

        System.out.println("学生" + stu1.getName + "的老师是:" + stu2.getTeacher().getName);

    }

}

运行结果：

学生test1的老师是：王老师

学生test2的老师是：王老师

观察以上运行结果，我们可以发现：在我们给学生2修改老师的时候，学生1的老师也跟着被修改了。这就是浅拷贝带来的问题。

我们可以通过深拷贝来解决这种问题，其实深拷贝就是基于浅拷贝来递归实现具体的每个对象，代码如下：

   public Student clone() {

        Student student = null;

        try {

            student = (Student) super.clone();

            Teacher teacher = this.teacher.clone();//克隆teacher对象

            student.setTeacher(teacher);

            } catch (CloneNotSupportedException e) {

            e.printStackTrace();

            }

            return student;

   }

适用场景

前面我详述了原型模式的实现原理，那到底什么时候我们要用它呢？

在一些重复创建对象的场景下，我们就可以使用原型模式来提高对象的创建性能。例如，我在开头提到的，循环体内创建对象时，我们就可以考虑用clone的方式来实现。

例如：

for(int i=0; i<list.size(); i++){

  Student stu = new Student();

  ...

}

我们可以优化为：

Student stu = new Student();

for(int i=0; i<list.size(); i++){

 Student stu1 = (Student)stu.clone();

  ...

}

除此之外，原型模式在开源框架中的应用也非常广泛。例如Spring中，@Service默认都是单例的。用了私有全局变量，若不想影响下次注入或每次上下文获取bean，就需要用到原型模式，我们可以通过以下注解来实现，@Scope(“prototype”)。

享元模式

享元模式是运用共享技术有效地最大限度地复用细粒度对象的一种模式。该模式中，以对象的信息状态划分，可以分为内部数据和外部数据。内部数据是对象可以共享出来的信息，这些信息不会随着系统的运行而改变；外部数据则是在不同运行时被标记了不同的值。

享元模式一般可以分为三个角色，分别为 Flyweight（抽象享元类）、ConcreteFlyweight（具体享元类）和 FlyweightFactory（享元工厂类）。抽象享元类通常是一个接口或抽象类，向外界提供享元对象的内部数据或外部数据；具体享元类是指具体实现内部数据共享的类；享元工厂类则是主要用于创建和管理享元对象的工厂类。

实现享元模式

我们还是通过一个简单的例子来实现一个享元模式：

//抽象享元类

interface Flyweight {

    //对外状态对象

    void operation(String name);

    //对内对象

    String getType();

}

//具体享元类

class ConcreteFlyweight implements Flyweight {

    private String type;



    public ConcreteFlyweight(String type) {

        this.type = type;

    }



    @Override

    public void operation(String name) {

        System.out.printf("[类型(内在状态)] - [%s] - [名字(外在状态)] - [%s]\n", type, name);

    }



    @Override

    public String getType() {

        return type;

    }

}

//享元工厂类

class FlyweightFactory {

    private static final Map<String, Flyweight> FLYWEIGHT_MAP = new HashMap<>();//享元池，用来存储享元对象



    public static Flyweight getFlyweight(String type) {

        if (FLYWEIGHT_MAP.containsKey(type)) {//如果在享元池中存在对象，则直接获取

            return FLYWEIGHT_MAP.get(type);

        } else {//在响应池不存在，则新创建对象，并放入到享元池

            ConcreteFlyweight flyweight = new ConcreteFlyweight(type);

            FLYWEIGHT_MAP.put(type, flyweight);

            return flyweight;

        }

    }

}

public class Client {



    public static void main(String[] args) {

        Flyweight fw0 = FlyweightFactory.getFlyweight("a");

        Flyweight fw1 = FlyweightFactory.getFlyweight("b");

        Flyweight fw2 = FlyweightFactory.getFlyweight("a");

        Flyweight fw3 = FlyweightFactory.getFlyweight("b");

        fw1.operation("abc");

        System.out.printf("[结果(对象对比)] - [%s]\n", fw0 == fw2);

        System.out.printf("[结果(内在状态)] - [%s]\n", fw1.getType());

    }

}

输出结果：

[类型(内在状态)] - [b] - [名字(外在状态)] - [abc]

[结果(对象对比)] - [true]

[结果(内在状态)] - [b]

观察以上代码运行结果，我们可以发现：如果对象已经存在于享元池中，则不会再创建该对象了，而是共用享元池中内部数据一致的对象。这样就减少了对象的创建，同时也节省了同样内部数据的对象所占用的内存空间。

适用场景

享元模式在实际开发中的应用也非常广泛。例如Java的String字符串，在一些字符串常量中，会共享常量池中字符串对象，从而减少重复创建相同值对象，占用内存空间。代码如下：

 String s1 = "hello";

 String s2 = "hello";

 System.out.println(s1==s2);//true

还有，在日常开发中的应用。例如，池化技术中的线程池就是享元模式的一种实现；将商品存储在应用服务的缓存中，那么每当用户获取商品信息时，则不需要每次都从redis缓存或者数据库中获取商品信息，并在内存中重复创建商品信息了。

总结

原型模式和享元模式，在开源框架，和实际开发中，应用都十分广泛。

在不得已需要重复创建大量同一对象时，我们可以使用原型模式，通过clone方法复制对象，这种方式比用new和序列化创建对象的效率要高；在创建对象时，如果我们可以共用对象的内部数据，那么通过享元模式共享相同的内部数据的对象，就可以减少对象的创建，实现系统调优。

本文由mdnic

Java字符串常量池和intern方法解析

这篇文章,来讨论一下Java中的字符串常量池以及Intern方法.这里我们主要讨论的是jdk1.7,jdk1.8版本的实现.

字符串常量池

在日常开发中,我们使用字符串非常的频繁,我们经常会写下类似如下的代码:

• String s = "abc";


• String str = s + "def";

通常,我们一般不会这么写:String s = new String("jkl"),但其实这么写和上面的写法还是有很多区别的.

先思考一个问题,为什么要有字符串常量池这种概念?原因是字符串常量既然是不变的,那么完全就可以复用它,而不用再重新去浪费空间存储一个完全相同的字符串.字符串常量池是用于存放字符串常量的地方,在Java7和Java8中字符串常量池是堆的一部分.

假如我们有如下代码:

String s = "abc";

String s1 = s + "def";    

String s2 = new String("abc");

String s3 = new String("def");

那么从内存分配的角度上看,最终会有哪些字符串生成呢,首先我先给出一张图来代表最终的结论,然后再分析一下具体的原因:

现在来依次分析上面的代码的执行流程:

0. 
   

   执行String s = "abc",此时遇到"abc"这个字符串常量,会在字符串常量池中完成分配,并且会将引用赋值给s,因此这条语句会在字符串常量池中分配一个"abc".(这里其实没有空格,是因为生成文章时出现了空格,下文中如果出现同样情况,请忽略空格)

   
   


1. 
   

   执行String s1 = s + "def",其实这个语句看似简单,实则另有玄机,它其实最终编译而成的代码是这样的:String s1 = new StringBuilder("abc").append("def").toString().首先在这个语句中有两个字符串常量:"abc"和"def",所以在字符串常量池中应该放置"abc"和"def",但是上个步骤已经有"abc"了,所以只会放置"def".另外,new StringBuilder("abc")这个语句相当于在堆上分配了一个对象,如果是new出来的,是在堆上分配字符串,是无法共享字符串常量池里面的字符串的,也就是说分配到堆上的字符串都会有新的内存空间. 最后toString()也是在堆中分配对象(可以从源码中看到这个动作),最终相当于执行了new String("abcdef");所以总结起来,这条语句分析起来还是挺麻烦的,它分配了以下对象:

   
   
   
   
   • 在字符串常量池分配"abc",但本来就有一个"abc"了,所以不需要分配
   
   
   • 在字符串常量池中分配“def"
   
   
   • 在堆中分配了"abc"
   
   
   • 在堆中分配了"abcdef"
   
   
   
   


2. 
   

   执行String s2 = new String("abc").首先有个字符串常量"abc",需要分配到字符串常量池,但是字符串常量池中已经有"abc"了,所以无需分配.因此new String("abc")最终在堆上分配了一个"abc".所以总结起来就是,在堆中分配了一个"abc"

   
   


3. 
   

   执行String s3 = new String("def");.首先有个字符串常量"def",需要分配到字符串常量池,但是字符串常量池中已经有"def"了,所以无需分配.因此new String("def")最终在堆上分配了一个"def".所以总结起来就是,在堆中分配了一个"def"。

   
   

总结起来,全部语句执行后分配的对象如下:

• 在堆中分配了两个"abc",一个"abcdef",一个"def"


• 在字符串常量池中分配了一个"abc",一个"def"

也就是图中所表示的这些对象,如果明白了对象是如何分配的,我们就可以分析以下代码的结果:

String s = "abc";

String s1 = s + "def";    

String s2 = new String("abc");

String s3 = new String("def");

String s4 = "abcdef";

String s5 = "abc";

System.out.println(s == s2); //false 前者引用的对象在字符串常量池 后者在堆上

System.out.println(s == s5);; //true 都引用了字符串常量池中的"abc"

System.out.println(s1 == s4); //false 前者引用的对象在字符串常量池,后者在堆上

intern方法

在字符串对象中,有一个intern方法.在jdk1.7,jdk1.8中,它的定义是如果调用这个方法时,在字符串常量池中有对应的字符串,那么返回字符串常量池中的引用,否则返回调用时相应对象的引用,也就是说intern方法在jdk1.7,jdk1.8中只会复用某个字符串的引用,这个引用可以是对堆内存中字符串中的引用,也可能是对字符串常量池中字符串的引用.这里通过一个例子来说明,假如我们有下面这段代码:

String str = new String("abc");

String str2 = str.intern();

String str3 = new StringBuilder("abc").append("def").toString();

String str4 = str3.intern();

System.out.println(str == str2);

System.out.println(str3 == str4);   

那么str2和str以及str3和str4是否相等呢?如果理解了上面对字符串常量池的分析,那么我们可以明白在这段代码中,字符串在内存中是这么分配的:

• 在堆中分配两个"abc",一个“abcdef"


• 在字符串常量池中分配一个"def",一个"abc"

1. 当执行String str2 = str.intern();时,会先从字符串常量池中寻找是否有对应的字符串,此时在字符串常量池中有一个"abc",那么str2就指向字符串常量池中的"abc",而str是new出来的,指向的是堆中的"abc",所以str不等于str2;

2. 当执行String str4 = str3.intern();会先从字符串常量池中寻找"abcdef",此时字符串常量池中并没有"abcdef",因此str4会指向堆中的"abcdef",因此str3等于str4,我们会发现一个有意思的地方:如果将第三句改成String str3 = new StringBuilder("abcdef").toString();,也就是把append后面的字符串和前面的字符串做一个拼接,那么结果就会变成str3不等于str4.所以这两种写法的区别还是挺大的.

要注意的是,在jdk1.6中intern的定义是如果字符串常量池中没有对应的字符串,那么就在字符串常量池中创建一个字符串,然后返回字符串常量池中的引用,也就是说在jdk1.6中,intern方法返回的对象始终都是指向字符串常量池的.如果上面的代码在jdk1.6中运行,那么就会得到两个false,原因如下:

1. 当执行String str2 = str.intern();时,会先从字符串常量池中寻找是否有对应的字符串,此时在字符串常量池中有一个"abc",那么str2就指向字符串常量池中的"abc",而str是new出来的,指向的是堆中的"abc",所以str不等于str2;

2. 当执行String str4 = str3.intern();会先从字符串常量池中寻找"abcdef",此时字符串常量池中并没有"abcdef",因此执行intern方法会在字符串常量池中分配"abcdef",然后str4最终等于这个字符串的引用,因此str3不等于str4,因为上面的str3指向堆,而str4指向字符串常量池,所以两者一定不会相等.

在深入理解JVM虚拟机一书中,就有类似的代码:

String str1 = new StringBuilder("计算机").append("软件").toString();

System.out.println(str1 == str1.intern());

String str2 = new StringBuilder("ja").append("va").toString();

System.out.println(str2 == str2.intern());

在jdk1.6中,两个判断都为false.因为str1和str2都指向堆,而intern方法得出来的引用都指向字符串常量池,所以不会相等,和上面叙述的结论是一样的.在jdk1.7中,第一个是true,第二个是false.道理其实也和上述所讲的是一样的,对于第一个语句,最终会在堆上创建一个"计算机软件"的字符串,执行str1.intern()方法时,先在字符串常量池中寻找字符串,但没有找到,所以会直接引用堆上的这个"计算机软件",因此第一个语句会返回true,因为最终都是指向堆.而对于第三个语句,因为和第一个语句差不多,按理说最终比较也应该返回true.但实际上,str2.intern方法执行的时候,在字符串常量池中是可以找到"java"这个字符串的,这是因为在Java初始化环境去加载类的时候(执行main方法之前),已经有一个叫做"java"的字符串进入了字符串常量池,因此str2.intern方法返回的引用是指向字符串常量池的,所以最终判断的结果是false,因为一个指向堆,一个指向字符串常量池.

总结

从上面的分析看来,字符串常量池并不像是那种很简单的概念,要深刻理解字符串常量池,至少需要理解以下几点:

• 理解字符串会在哪个内存区域存放


• 理解遇到字符串常量会发生什么


• 理解new String或者是new StringBuilder产生的对象会在哪里存放


• 理解字符串拼接操作+最终编译出来的语句是什么样子的


• 理解toString方法会发生什么

这几点都在本文章中覆盖了,相信理解了这几点之后一定对字符串常量池有一个更深刻的理解.其实这篇文章的编写原因是因为阅读深入理解JVM虚拟机这本书的例子时突然发现作者所说的和我所想的是不一样的,但是书上可能对这方面没有展开叙述,所以我去查了点资料,然后写了一些代码来验证,最终决定写一篇文章来记录一下自己的理解,在编写代码过程中,还发现了一个分析对象内存地址的类库,我放在参考资料中了.

参考资料

http://www.baeldung.com/java-object… 查看java对象内存地址

欢迎关 Android茶话会 在技术学习、个人成长的道路上，让我们一起前进！

一、什么是SysTrace？

在日常开发中有时候遇到棘手的性能问题就需要使用这个工具，Systrace 是 「Android 4.1」 中新增的性能数据采样和分析工具。它可帮助开发者收集 Android 关键子系统
（如 SurfaceFlinger/SystemServer/Kernel/Input/Display 等 Framework 部分关键模块、服务，View」系统等 的运行信息，从而帮助开发者更直观的「分析系统瓶颈，改进性能」。

二、如何使用SysTrace？

2.1 采集trace

首先我们需要了解Trace的采集主要涉及几部分：采集方式、自定义trace阶段、Release包抓取Trace和系统Trace类同异步调用的差异；

命令行采集：

• 设备要求**「Android 4.3 (API level 18)及以上」**


• 命令如下：python systrace.py [options][「categories」]，示例如下：

python /Users/yangzhiyong/Library/Android/sdk/platform-tools/systrace/systrace.py -t 10 -o trace.html gfx input view sched freq wm am hwui workq res dalvik sync disk load perf hal rs idle mmc -a com.ss.android.lark.debug



# -o : 指示输出文件的路径和名字

# -t : 抓取时间(最新版本可以不用指定, 按 Enter 即可结束)，单位为秒

# -b : 指定 buffer 大小 (一般情况下,默认的 Buffer 是够用的,如果你要抓很长的 Trae , 那么建议调大 Buffer )

# -a : 指定 app 包名 (如果要 Debug 自定义的 Trace 点, 记得要加这个)

• 
  

  查看支持的categories

  
  
  
  
  • adb shell atrace --list_categories
  
  
  • python systrace.py -l
  
  
  
  

// 粗体部分是常用的categories;

         gfx - Graphics

       input - Input

        view - View System

     webview - WebView

          wm - Window Manager

          am - Activity Manager

          sm - Sync Manager

       audio - Audio

       video - Video

      camera - Camera

         hal - Hardware Modules

         res - Resource Loading

      dalvik - Dalvik VM

          rs - RenderScript

      bionic - Bionic C Library

       power - Power Management

          pm - Package Manager

          ss - System Server

    database - Database

     network - Network

         adb - ADB

    vibrator - Vibrator

        aidl - AIDL calls

         pdx - PDX services

       sched - CPU Scheduling

        freq - CPU Frequency

        idle - CPU Idle

        disk - Disk I/O

        sync - Synchronization

  memreclaim - Kernel Memory Reclaim

  binder_driver - Binder Kernel driver

  binder_lock - Binder global lock trace

系统自带工具：

• 
  

  设备要求**「Android 9(API level 28)及其以上」**

  
  


• 
  

  开发者模式->系统跟踪

  
  


• 
  

  trace导出：

  
  
  
  
  • 通知栏分享；
  
  
  • adb pull /data/local/traces/ .
  
  
  • systrace --from-file .ctrace .perfetto-trace 转换成html
  
  
  
  

网页版采集分析工具：💻

• 设备要求**「Android 10(API level 29)及其以上；」**


• Perfetto UI

❝

除此之外还有一些常用的技巧

❞

1. 自定义TAG

具体使用可参考：developer.android.com/topic/perfo…

• 
  

  「定义」

  
  
  
  
  • 在事件开始调用Trace.beginSection(event)；
  
  
  • 在事件结束调用Trace.endSection()，需成对调用；
  
  
  
  


• 
  

  「使用」 添加了自定义TAG后，需要-a指定包名参数，才可以采集到自定义的trace信息；

  
  

2. Release包抓取trace

反射调用setAppTracingAllowed即可：

try {

    Class threadClazz = Class.forName("android.os.Trace");

    Method setAppTracingAllowed = threadClazz.getDeclaredMethod("setAppTracingAllowed", boolean.class);

    setAppTracingAllowed.invoke(null, true);

} catch (Exception e) {

    e.printStackTrace();

}

3. 同异步trace的差异

2.2 分析

拿到这些trace 我们如何分析也是一个重要的部分

2.2.1 Trace文件打开

首先是打开这个文件

1. chrome://tracing：推荐：不过近期版本该工具对trace中线程、进程名解析不出来，不利于查看；


2. ui.perfetto.dev/#!/： 推荐，不过新版分析工具不支持VSync的高亮；


3. perfetto.bytedance.net/#!/viewer： 不推荐，仅支持单进程查看，对于涉及系统调用的分析不方便；

较早版本sysTrace生成的html文件浏览器即可打开，但最近版本已无法正常打开，需要通过chrome工具手动加载；

2.2.2 面板区域说明

image.png

1. 用户屏幕交互


2. CPU 使用率


3. CPU各核心的运行情况


4. 进程信息


5. 进程变量/进程


6. 选中区段的详细信息


7. 鼠标操作选项，可通过1-4快速切换


8. 进程过滤


9. VSync高亮配置

2.2.3 常用快捷键

比较常用的快捷键是W S A D M V；

• W : 放大 Systrace，放大可以更好地看清局部细节


• S : 缩小 Systrace，缩小以查看整体


• A : 左移


• D : 右移


• M : 高亮选中当前鼠标点击的段（这个比较常用，可以快速标识出这个方法的左右边界和执行时间，方便上下查看）


• V : 高亮VSync的时机，方便分析掉帧的原因；

image.png

2.2.4 线程状态

a) 线程状态

「线程状态」	「Systrace中的显示」	「说明」
绿色 : 运行中（Running）		我们经常会查看 Running 状态的线程，查看其运行的时间，与竞品做对比，分析快或者慢的原因
蓝色 : 可运行（Runnable）		Runnable 状态的线程状态持续时间越长，则表示 cpu 的调度越忙，没有及时处理到这个任务
白色 : 休眠中（Sleep）		一般是在等事件驱动
橘色 : 不可中断的睡眠态 IO Block（Uninterruptible Sleep WakeKill）		一般是标示 IO 操作慢，如果有大量的橘色不可中断的睡眠态出现，那么一般是由于进入了低内存状态
紫色 : 不可中断的睡眠态（Uninterruptible Sleep）		一般是陷入了内核态，有些情况下是正常的，有些情况下是不正常的，需要按照具体的情况去分析

b) 线程唤醒

一个任务在进入 Running 状态之前，会先进入 Runnable 状态进行等待，而 Systrace 会把这个状态也标示在 Systrace 上； stateWhenDescheduled定义：chromium.googlesource.com/external/tr…

c) 线程参数说明

• Wall Duration：函数执行的总耗时


• CPU Duration：在 CPU 上执行的耗时


• Self Time：自身执行的总耗时，不包括子方法


• CPU Self Time：自身在 CPU 上执行的耗时，不包括子方法

d) 函数调用虚实区别

如下图，我们看到标识setUpHWComposer调用的紫色条并不是实心的，实心的部分代表CPU Duration相对于Wall Duration的占比：

2.2.5 CPU信息

image.png

1. C-State

为了在CPU空闲的时候降低功耗，CPU可以被命令进入low-power模式。每个CPU都有几种power模式，这些模式被统称为C-states或者C-modes； C-States从C0开始，C0是CPU的正常工作模式，CPU处于100%运行状态。C后的数越高，CPU睡眠得越深，CPU的功耗被降低得越多，同时需要更多的时间回到C0模式。

1. Clock Frequency：CPU当前运行频率；


2. Clock Frequency Limits：CPU最大最小频率，通过该参数可以判断CPU核心差异，如大中小核

2.2.6 常见系统进程、线程

• 
  

  进程

  
  
  
  
  • 
    

    system_server

    
    
    
    
    • AMS
    
    
    • WMS
    
    
    • SurfaceFlinger
    
    
    
    
  
  
  
  


• 
  

  线程

  
  
  
  
  • UI Thread //主线程
  
  
  • Render Thread //渲染线程
  
  
  • Binder Thread //跨进程调用线程
  
  
  
  

2.2.7 常见问题

a) 「锁等待」

「monitor contention」 with owner 「caton_dump_stack (11056)」 waiters=0 blocking from 「boolean android.os.MessageQueue.enqueueMessage(android.os.Message, long)(MessageQueue.java:544)」 结合代码看，这段信息的意思是，「caton_dump_stack」线程（线程ID是11056）作为「owner」持有了主线程消息队列对象锁，「waiters」表示等待在该对象锁上的其他线程数（不包括当前线程），所以总的有1个线程等待对象锁释放，当前线程等待的位置是「enqueueMessage调用处」。

b) 「SurfaceFlinger绘制」

SurfaceFlinger主要是收集各个UI渲染层的数据合成发送给Hardware Composer；一般应用的渲染层包括状态栏、应用页面、导航栏，每个部分都是单独渲染生成Buffer的，基本步骤如下：

1. 应用收到VSYNC-app信号后，在**「UI Thread」完成数据计算；准备好后，将数据发送到「RenderThread」**；


2. 应用在**「RenderThread」完成数据渲染后，将数据填充到「SurfaceFlinger」**的对应页面BufferQueue中；


3. 在**「SurfaceFlinger」收到VSYNC-sf信号后，「SurfaceFlinger」** 会遍历它的层列表的BufferQueue，以寻找新的缓冲区。如果找到新的缓冲区，它会获取该缓冲区；否则，它会继续使用以前获取的缓冲区。「SurfaceFlinger」 必须始终显示内容，因此它会保留一个缓冲区。如果在某个层上没有提交缓冲区，则该层会被忽略；


4. **「SurfaceFlinger」**向 「HWC」 提供一个完整的层列表，并询问“您希望如何处理这些层？”


5. 「HWC」 的响应方式是将每个层标记为叠加层或 GLES 合成；


6. 「SurfaceFlinger」 会处理所有 GLES 合成，将输出缓冲区传送到 「HWC」，并让 「HWC」 处理其余部分；

image.png

c) 「掉帧」

上一部分描述了SurfaceFlinger合成每帧数据的过程，在上述过程中，如果**「UI Thread」计算不及时，或者「RenderThread」渲染不及时，或者「BufferQueue」**中可用Buffer不足导致在下一次VSYNC信号来临之前，没有准备好需要显示的帧的数据，就会出现丢帧，Systrace 报告列出了渲染界面帧的每个进程，并指明了沿时间轴渲染的每个帧。在 16.6 毫秒内渲染的必须保持每秒 60 帧稳定帧速率的帧会以绿色圆圈表示。渲染时间超过 16.6 毫秒的帧会以黄色或红色帧圆圈表示：

1. 绿色：未丢帧；


2. 棕色：轻微丢帧，丢1帧 ；


3. 红色：严重丢帧，丢大于1帧；

通过Systrace右上角的View Options > Highlight VSync，我们可以高亮VSYNC信号到来的时刻，需要注意的是，高亮的VSYNC主要是VSYNC-app信号（可在SurfaceFlinger进程中查看），且灰白相间的位置是VSYNC信号到来的时刻。 如下图，显示了丢1帧的情况，第二个VSYNC到来时，主线程仍未完成显示帧数据的计算，所以出现丢帧的问题。

三、常见trace工具对比

其实我们分析trace不光只有系统这一种方法，下图做个简单的总结

「instrument」：获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。

「sample」：有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心。

事情是这样的，这天我醒来，觉得身为一个 “ikun”，我得向我的giegie看齐，早点把篮球水平练上去，早点追上我的giegie，于是我便开始了我的打球(打铁)之旅~

突发奇想

晚上，当我在分析着我的打球视频时，我又感觉我做这些是远远不够的！我要将这一切融入到前端里，让别人知道，咱们 ”ikun“ 是一个爱giegie，也爱学习的团体！我想要达到以下的效果

于是我想，我能不能把这个打球(打铁)视频，在控制台里 console.log 出来呢？我在心里演练了一遍，我觉得是可行的，我的思路有两个

直接用 console.log 输出视频？

好吧，目前 console.log 不支持输出视频吧~此路不通啊！

细分成每一帧去输出？

这个方式的思路具体分为以下几步：

• 捕获视频的每一帧


• 将每一帧转换成图片


• 使用console.log输出生图片

如何捕获视频的每一帧？

使用 video 的 requestVideoFrameCallback 方法即可，requestVideoFrameCallback() 是一个新的WEB API，2021 年 1 月 25 日提交的草案。requestVideoFrameCallback() 方法允许WEB开发者注册一个回调方法，回调方法在新视频帧发送到合成器时在渲染步骤中运行。这是为了让开发人员对视频执行高效的每帧视频操作，例如视频处理和绘制到画布上（截屏）、视频分析或与外部音频源同步。

如何将每一帧转换成图片？

这得使用 canvas来完成，主要依赖了两个方法

• ctx.drawImage：将一帧画面画到 canvas 上


• canvas.toDataURL('image/png')：将 canvas 画布上的图像转成base64的URL

console.log 能输出图片？

console.log 是可以输出图片了，这一特性很久前就有了~不信你们复制以下代码，去尝试一下~

console.log(

  "%c image",

  `background-image: url(https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ca412c9f87fb4df1b5402a5ad64474f1~tplv-k3u1fbpfcp-watermark.image?);

   background-size: contain;

   background-repeat: no-repeat;

   padding: 200px;

  `

)

开始实现吧~

那我们开始实现吧，我这边的技术栈是 Vue3哦~

先看看效果

先看看效果是怎么样的

初始化代码

我们需要 video 和 canvas，这两个标签，前者是视频标签，后者是画布标签

<template>

  <video ref="videoRef" width="640" height="360" controls playsinline muted>

    <source src="./kunkun.mp4" />

    您的浏览器不支持 video 标签。

  video>

  <canvas ref="canvasRef" width="640" height="360">canvas>

template>

封装 useIKun

封装一个 Vue3 的 hooks，名为 useIKun，用来处理 ikun 的打球视频转换图片输出~

接下来我们开始封装 useIKun

import { onMounted } from 'vue'

import type { Ref } from 'vue'



const CANVAS_WIDTH_BASE = 220

const CANVAS_HEIGHT_BASE = 220



export const useIKun = ({

  videoInstance,

  canvasInstance,

}: {

  videoInstance: Ref

  canvasInstance: Ref

}) => {

  onMounted(() => {

    // 播放视频

    handleVideoPlay()

  })



  // 获取dom实例

  const getInstances = () => {

    const video = videoInstance.value

    const canvas = canvasInstance.value

    return {

      video,

      canvas,

    }

  }



  // 获取canvas尺寸信息

  const getCanvasSize = () => {

    const { video } = getInstances()

    // videoWidht、videoHeight视频原始宽度、高度(单位:px)

    const width = video.videoWidth

    const height = video.videoHeight



    const rate = height / width



    return {

      width: CANVAS_WIDTH_BASE,

      height: CANVAS_HEIGHT_BASE * rate,

    }

  }



  const handleVideoPlay = () => {

    const video = videoInstance.value

    const canvas = canvasInstance.value

    video.oncanplay = () => {

      const { width, height } = getCanvasSize()

      canvas.width = width

      canvas.height = height

      video.play() // 播放视频



      // 判断HTMLVideoElement是否支持requestVideoFrameCallback()方法

      if ('requestVideoFrameCallback' in video) {

        // 下此视频帧呈现时触发回调

        video.requestVideoFrameCallback(updateVideo)

      }

    }

  }



  /*

   * 根据当前视频帧绘制图片

   */

  const updateVideo = () => {

    const video = videoInstance.value

    const canvas = canvasInstance.value

    const ctx = canvas.getContext('2d')

    if (ctx) {

      const { width, height } = getCanvasSize()

      ctx.drawImage(video, 0, 0, width, height) // 使用视频帧(当前帧)绘制canvas

      const dataURL = canvas.toDataURL('image/png')

      console.log(

        '%c image',

        `background-image: url(${dataURL});

          background-size: contain;

          background-repeat: no-repeat;

          padding: 200px;

    `,

      )

      video.requestVideoFrameCallback(updateVideo)

    }

  }

}

console.clear() ?

我们可以看到效果出来了，控制台里确实“播放了视频”，但其实不是视频，其实是以非常快的速度，去打印出一帧一帧的图片出来，由于速度很快，所以给你一种在放视频的假象，不信你看其实控制台里不止一个画面哦~

所以我们咋办，每次输出图片的时候用 console.clear() 清除一下吗？我们可以试试~

  const updateVideo = () => {

    const video = videoInstance.value

    const canvas = canvasInstance.value

    const ctx = canvas.getContext('2d')

    if (ctx) {

      const { width, height } = getCanvasSize()

      ctx.drawImage(video, 0, 0, width, height) // 使用视频帧(当前帧)绘制canvas

      const dataURL = canvas.toDataURL('image/png')

      // 清除

+      console.clear()

      console.log(

        '%c image',

        `background-image: url(${dataURL});

          background-size: contain;

          background-repeat: no-repeat;

          padding: 200px;

    `,

      )

      video.requestVideoFrameCallback(updateVideo)

    }

  }

再来看看效果~ 显然这样是不行的，console.clear 会导致闪烁问题~

Gif图？

所以我又有新思路，将每一帧的图像收集起来，然后组成一个 Gif 图，然后输出在控制台，不就行了！！！

gifshot

想要完成这个事情，就要借助这个库——gifshot，他的作用是可以把你传给他的图像数组，组成一个 gif图

重新封装 useIKun

 import { onMounted, ref } from 'vue'

import type { Ref } from 'vue'

import gifshot from 'gifshot'



const CANVAS_WIDTH_BASE = 220

const CANVAS_HEIGHT_BASE = 220

const IMG_SPAN = 5



export const useIKun = ({

  videoInstance,

  canvasInstance,

}: {

  videoInstance: Ref

  canvasInstance: Ref

}) => {

  const imgs = ref<string[]>([])



  onMounted(() => {

    // 播放视频

    handleVideoPlay()

    // 监听播放结束

    onVideoEnded()

  })



  const getInstances = () => {

    const video = videoInstance.value

    const canvas = canvasInstance.value

    return {

      video,

      canvas,

    }

  }



  const getCanvasSize = () => {

    const { video } = getInstances()

    // videoWidht、videoHeight视频原始宽度、高度(单位:px)

    const width = video.videoWidth

    const height = video.videoHeight



    const rate = height / width



    return {

      width: CANVAS_WIDTH_BASE,

      height: CANVAS_HEIGHT_BASE * rate,

    }

  }



  /*

   * 控制视频播放

   */

  const handleVideoPlay = () => {

    const { video, canvas } = getInstances()

    video.oncanplay = () => {

      const { width, height } = getCanvasSize()

      canvas.width = width

      canvas.height = height

      video.play() // 播放视频



      // 判断HTMLVideoElement是否支持requestVideoFrameCallback()方法

      if ('requestVideoFrameCallback' in video) {

        // 下此视频帧呈现时触发回调

        video.requestVideoFrameCallback(updateVideo)

      }

    }

  }



  /*

   * 根据当前视频帧绘制图片

   */

  const updateVideo = () => {

    const { video, canvas } = getInstances()

    const ctx = canvas.getContext('2d')

    if (ctx) {

      const { width, height } = getCanvasSize()

      ctx.drawImage(video, 0, 0, width, height) // 使用视频帧(当前帧)绘制canvas

      const dataURL = canvas.toDataURL('image/png')

      imgs.value.push(dataURL)

      video.requestVideoFrameCallback(updateVideo)

    }

  }



  /*

   * 监听视频停止播放

   */

  const onVideoEnded = () => {

    const { video } = getInstances()

    video.onended = () => {

      console.log('播放完了')

      console.log(imgs.value.length)

      const currentImgs = imgs.value

      const resultImgs: string[] = []

      currentImgs.forEach((img, index) => {

        // 稀释图片数组，怕太大太久~你们也可以选择不走这一步

        if (index % IMG_SPAN === 0) {

          resultImgs.push(img)

        }

      })

      // gifshot转换gif

      gifshot.createGIF(

        {

          fps: 10,

          width: 220,

          height: 500,

          images: resultImgs,

        },

        (obj) => {

          console.log(obj)

          if (!obj.error) {

            const url = obj.image

            // 输出最终的gif地址

            console.log(

              '%c image',

              `background-image: url(${url});

          background-size: contain;

          background-repeat: no-repeat;

          padding: 200px;

    `,

            )

          }

        },

      )

    }

  }

}

结果

哎，，，这画质，虽然比较糙，但是也算是本 ikun 为 giegie做出的一点点贡献了~

结语 & 加学习群 & 摸鱼群

我是林三心

• 一个待过小型toG型外包公司、大型外包公司、小公司、潜力型创业公司、大公司的作死型前端选手；


• 一个偏前端的全干工程师；


• 一个不正经的掘金作者；


• 一个逗比的B站up主；


• 一个不帅的小红书博主；


• 一个喜欢打铁的篮球菜鸟；


• 一个喜欢历史的乏味少年；


• 一个喜欢rap的五音不全弱鸡